Calling of GetVolumeInformation returns empty serial number
Hi!
Windows 10, Python 3.6.
I want to get the serial number of the drives (without external modules
like Win32 or WMI).
It is needed for identification of removable devices (like USB external
drives).
Somewhere I saw this code:
def GetVolumeID(Drive):
import ctypes
kernel32 = ctypes.windll.kernel32
volumeNameBuffer = ctypes.create_unicode_buffer(1024)
fileSystemNameBuffer = ctypes.create_unicode_buffer(1024)
serial_number = None
max_component_length = None
file_system_flags = None
rc = kernel32.GetVolumeInformationW(
ctypes.c_wchar_p(Drive),
volumeNameBuffer,
ctypes.sizeof(volumeNameBuffer),
serial_number,
max_component_length,
file_system_flags,
fileSystemNameBuffer,
ctypes.sizeof(fileSystemNameBuffer)
)
return serial_number;
print(GetVolumeID('c:\\'))
This function is working with other values (volumeNameBuffer), but for
serial it returns None.
The serial number is empty.
How to I pass this parameter to I get the value?
The doc said it's LPDWORD (pointer to DWORD):
https://msdn.microsoft.com/en-us/library/windows/desktop/aa364993(v=vs.85).aspx
_Out_opt_ LPDWORD lpVolumeSerialNumber,
Thank you for any advance in this theme!
Best wishes
dd
--
https://mail.python.org/mailman/listinfo/python-list
Re: Calling of GetVolumeInformation returns empty serial number
On 2017-11-07 08:58, Durumdara wrote:
> Hi!
>
> Windows 10, Python 3.6.
>
> I want to get the serial number of the drives (without external modules
> like Win32 or WMI).
> It is needed for identification of removable devices (like USB external
> drives).
>
> Somewhere I saw this code:
>
> def GetVolumeID(Drive):
> import ctypes
> kernel32 = ctypes.windll.kernel32
> volumeNameBuffer = ctypes.create_unicode_buffer(1024)
> fileSystemNameBuffer = ctypes.create_unicode_buffer(1024)
> serial_number = None
> max_component_length = None
> file_system_flags = None
>
> rc = kernel32.GetVolumeInformationW(
> ctypes.c_wchar_p(Drive),
> volumeNameBuffer,
> ctypes.sizeof(volumeNameBuffer),
> serial_number,
> max_component_length,
> file_system_flags,
> fileSystemNameBuffer,
> ctypes.sizeof(fileSystemNameBuffer)
> )
> return serial_number;
>
> print(GetVolumeID('c:\\'))
>
>
> This function is working with other values (volumeNameBuffer), but for
> serial it returns None.
> The serial number is empty.
> How to I pass this parameter to I get the value?
Do you get a value for max_component_length? (I wouldn't expect so, but
that is what you imply).
Anyway, the ctypes docs are pretty clear:
https://docs.python.org/3/library/ctypes.html#passing-pointers-or-passing-parameters-by-reference
>
> The doc said it's LPDWORD (pointer to DWORD):
>
> https://msdn.microsoft.com/en-us/library/windows/desktop/aa364993(v=vs.85).aspx
>
> _Out_opt_ LPDWORD lpVolumeSerialNumber,
>
>
> Thank you for any advance in this theme!
>
> Best wishes
>dd
>
--
Thomas Jollans
--
https://mail.python.org/mailman/listinfo/python-list
PyDev 6.1.0 Released
PyDev 6.1.0 Release Highlights - *Important* PyDev now requires Java 8 and Eclipse 4.6 (Neon) onwards. - PyDev 5.2.0 is the last release supporting Eclipse 4.5 (Mars). - *Code Formatter* - The PyDev code formatter can now add/remove blank lines to comply with pep-8. - Added preference to skip blank lines formatting. - *Editor* - Editor now tolerant against errors in the definitions of style ranges. - When in link mode (after a code completion with params for instance), properly skip closing parenthesis if already well balanced. - Fix logic error in editor preferences for disabling subword navigation (patch by *Stuart Berg*). - *Others* - Using *python -m 'pip'* when unable to find pip executable in interpreter preferences (*#PyDev-853*). - PyDev set next statement action set no longer disables Debug action set (*#PyDev-859*). - It's possible to silence question about saving resources before a refactoring operation. - Add problem markers for python files that declare invalid encodings (patch by *Mat Booth*). - Other minor bugfixes. What is PyDev? PyDev is an open-source Python IDE on top of Eclipse for Python, Jython and IronPython development. It comes with goodies such as code completion, syntax highlighting, syntax analysis, code analysis, refactor, debug, interactive console, etc. Details on PyDev: http://pydev.org Details on its development: http://pydev.blogspot.com What is LiClipse? LiClipse is a PyDev standalone with goodies such as support for Multiple cursors, theming, TextMate bundles and a number of other languages such as Django Templates, Jinja2, Kivy Language, Mako Templates, Html, Javascript, etc. It's also a commercial counterpart which helps supporting the development of PyDev. Details on LiClipse: http://www.liclipse.com/ Cheers, -- Fabio Zadrozny -- Software Developer LiClipse http://www.liclipse.com PyDev - Python Development Environment for Eclipse http://pydev.org http://pydev.blogspot.com PyVmMonitor - Python Profiler http://www.pyvmmonitor.com/ -- https://mail.python.org/mailman/listinfo/python-list
Re: Easiest way to access C module in Python
On 07/11/2017 02:23, Chris Angelico wrote:
On Tue, Nov 7, 2017 at 12:52 PM, bartc wrote:
Cython seems very confusing to me.
Otherwise what /I/ would look for is ways to call C functions inside shared
libraries (.dll and .so). That requires that the modules under test be
wrapped as a shared library, which may be extra effort (but it will still be
using C, so with familiar tools and no crossover with Python at this point).
To call shared library C functions from Python I think involves the ctypes
module (I've never done it). Googling 'ctypes shared library' gives some
promising results.
The point of Cython is to make this easier. It's worth learning.
My experience is different.
I created a function fred() in a C module, then linked that into a .dll
(.so on Linux should be similar).
Then I wrote this code, adapted from the first hit I found for 'python
ctypes example':
import ctypes
testlib = ctypes.CDLL('c:/c/c.dll')
testlib.fred()
And it worked perfectly (on Py2 and Py3). (I understand passing
arguments is a bit more complicated, but at least you have a working base.)
Then I tried the first example I saw for 'cython examples' which was
this, first create a .pyx file as suggested, then:
from distutils.core import setup
from Cython.Build import cythonize
setup(ext_modules=cythonize("helloworld.pyx"))
It spend several seconds thinking about it, then I got this enlightening
error report:
17.297
Traceback (most recent call last):
File "c:\langs\a.py", line 10, in
from distutils.core import setup
File "c:\python36\lib\distutils\core.py", line 16, in
from distutils.dist import Distribution
File "c:\python36\lib\distutils\dist.py", line 10, in
from email import message_from_file
ImportError: cannot import name 'message_from_file'
That was Py3; on Py2, I had 30 seconds of disk activity, and nearly full
memory that almost stalled my machine before I aborted it. (Actually I
mispelled both 'cythonize's in the example; it didn't make any difference).
And I still have no idea how to relate this to calling a native C
function in an external shared library.
--
bartc
--
https://mail.python.org/mailman/listinfo/python-list
Re: Easiest way to access C module in Python
On Tue, Nov 7, 2017 at 10:06 PM, bartc wrote: > On 07/11/2017 02:23, Chris Angelico wrote: >> >> On Tue, Nov 7, 2017 at 12:52 PM, bartc wrote: > > >>> Cython seems very confusing to me. >> >> > >> >>> Otherwise what /I/ would look for is ways to call C functions inside >>> shared >>> libraries (.dll and .so). That requires that the modules under test be >>> wrapped as a shared library, which may be extra effort (but it will still >>> be >>> using C, so with familiar tools and no crossover with Python at this >>> point). >>> >>> To call shared library C functions from Python I think involves the >>> ctypes >>> module (I've never done it). Googling 'ctypes shared library' gives some >>> promising results. >> >> >> The point of Cython is to make this easier. It's worth learning. > > > My experience is different. Thanks for the FUD. I love it when someone, on the basis of one failed experiment, trash-talks an excellent piece of software that would solve the OP's problem. ChrisA -- https://mail.python.org/mailman/listinfo/python-list
Re: Easiest way to access C module in Python
On 07/11/2017 11:16, Chris Angelico wrote: On Tue, Nov 7, 2017 at 10:06 PM, bartc wrote: My experience is different. Thanks for the FUD. I love it when someone, on the basis of one failed experiment, trash-talks an excellent piece of software that would solve the OP's problem. OK, I gave a working example that called an actual C function. Perhaps you can give one based on Cython that does the same thing. -- https://mail.python.org/mailman/listinfo/python-list
Re: Easiest way to access C module in Python
On 7 November 2017 at 11:16, Chris Angelico wrote: > Thanks for the FUD. I love it when someone, on the basis of one failed > experiment, trash-talks an excellent piece of software that would > solve the OP's problem. It *is* true that the learning curve for Cython is steeper than that of ctypes. But for anything more complex than simple "call a function with no arguments", ctypes rapidly gets fairly complex and messy - and the docs are not exactly the best. At that point, investing the time in learning how to use Cython definitely pays off. Another option for the OP is cffi, which might offer a middle ground (in terms of complexity vs power - it's hard to objectively assess "complexity" without knowing the audience's background). Paul -- https://mail.python.org/mailman/listinfo/python-list
Re: Easiest way to access C module in Python
On 07/11/2017 11:35, Paul Moore wrote: On 7 November 2017 at 11:16, Chris Angelico wrote: Thanks for the FUD. I love it when someone, on the basis of one failed experiment, trash-talks an excellent piece of software that would solve the OP's problem. It *is* true that the learning curve for Cython is steeper than that of ctypes. But for anything more complex than simple "call a function with no arguments", ctypes rapidly gets fairly complex and messy - and the docs are not exactly the best. At that point, investing the time in learning how to use Cython definitely pays off. But just staying with the "function with no arguments" for the minute (the equivalent of Hello World for this exercise), how would it be done in Cython? Would a working example be simple enough to show in a usenet post? Another option for the OP is cffi, And perhaps another example here. (cffi doesn't seem to be part of any of my pythons, so that would be an obstacle for me as installing extra stuff rarely seems to work. Having said that, I located pip.exe, trying typing 'pip install cffi' and it seemed to be doing something but then failed with a bunch of errors.) -- bartc -- https://mail.python.org/mailman/listinfo/python-list
Re: Calling of GetVolumeInformation returns empty serial number
On Tue, Nov 7, 2017 at 7:58 AM, Durumdara wrote:
>
> I want to get the serial number of the drives (without external modules
> like Win32 or WMI).
The volume serial number is more easily available as
os.stat(drive).st_dev, which comes from calling
GetFileInformationByHandle. Note that despite using the volume serial
number (VSN) as the nearest equivalent of POSIX st_dev, there is no
requirement that the VSN is unique or even non-zero. The same applies
to the file index number that's used for POSIX st_ino. For example,
both values are 0 on a WebDav drive, for which Python's implementation
of os.path.samefile is useless. Practically speaking, however, it's
good enough in most cases, especially for mounted disk volumes.
That said, maybe what you really want is the hardware (disk) serial
number -- not a volume serial number. The easiest way to get that is
via WMI. You can use subprocess to run wmic.exe if you don't want an
external dependency. You can also get the disk serial number by
calling DeviceIoControl via ctypes. This is a fairly complex
IOCTL_STORAGE_QUERY_PROPERTY request, with an input
STORAGE_PROPERTY_QUERY structure requesting the StorageDeviceProperty.
The result is a STORAGE_DEVICE_DESCRIPTOR structure that has a
SerialNumberOffset field that's the byte offset from the beginning of
the buffer of the serial number as a null-terminated string.
Getting back to the VSN, note that the mount-point manager doesn't
rely on it as a unique identifier. For associating volume devices with
logical DOS drives and volume GUID names (i.e. names like
"Volume{12345678----123456789abc}", which are used to
mount volumes as NTFS junctions), the mount-point manager queries a
unique ID via IOCTL_MOUNTDEV_QUERY_UNIQUE_ID. Sometimes the volume
driver returns a unique ID that's very long -- over 200 bytes. This
doesn't matter because it's only used to uniquely associate a GUID
name (and maybe a DOS drive) with the given volume when the system
boots. This association is persisted in HKLM\System\MountedDevices.
--
https://mail.python.org/mailman/listinfo/python-list
Re: Easiest way to access C module in Python
bartc writes:
> But just staying with the "function with no arguments" for the minute (the
> equivalent of Hello World for this exercise), how would it be done in
> Cython? Would a working example be simple enough to show in a usenet post?
fred.c::
int fred(void) {
return 42;
}
life.pyx::
cdef extern:
int fred()
def life():
return fred()
setup.py::
from distutils.core import setup
from distutils.extension import Extension
from Cython.Build import cythonize
setup(
ext_modules = cythonize([Extension("life", ["life.pyx", "fred.c"])])
)
$ python setup.py build_ext --inplace
Compiling life.pyx because it changed.
[1/1] Cythonizing life.pyx
running build_ext
building 'life' extension
creating build
creating build/temp.linux-x86_64-3.6
x86_64-linux-gnu-gcc -pthread -DNDEBUG -g -fwrapv -O2 -Wall -Wstrict-prototypes
-g -fdebug-prefix-map=/build/python3.6-5reRaQ/python3.6-3.6.3=.
-specs=/usr/share/dpkg/no-pie-compile.specs -fstack-protector-strong -Wformat
-Werror=format-security -Wdate-time -D_FORTIFY_SOURCE=2 -fPIC -I/tmp/ct/include
-I/usr/include/python3.6m -c life.c -o build/temp.linux-x86_64-3.6/life.o
x86_64-linux-gnu-gcc -pthread -DNDEBUG -g -fwrapv -O2 -Wall -Wstrict-prototypes
-g -fdebug-prefix-map=/build/python3.6-5reRaQ/python3.6-3.6.3=.
-specs=/usr/share/dpkg/no-pie-compile.specs -fstack-protector-strong -Wformat
-Werror=format-security -Wdate-time -D_FORTIFY_SOURCE=2 -fPIC -I/tmp/ct/include
-I/usr/include/python3.6m -c fred.c -o build/temp.linux-x86_64-3.6/fred.o
x86_64-linux-gnu-gcc -pthread -shared -Wl,-O1 -Wl,-Bsymbolic-functions
-specs=/usr/share/dpkg/no-pie-link.specs -Wl,-z,relro
-specs=/usr/share/dpkg/no-pie-link.specs -Wl,-z,relro -g
-fdebug-prefix-map=/build/python3.6-5reRaQ/python3.6-3.6.3=.
-specs=/usr/share/dpkg/no-pie-compile.specs -fstack-protector-strong -Wformat
-Werror=format-security -Wdate-time -D_FORTIFY_SOURCE=2
build/temp.linux-x86_64-3.6/life.o build/temp.linux-x86_64-3.6/fred.o -o
/tmp/ct/life.cpython-36m-x86_64-linux-gnu.so
$ python -c "import life; print(life.life())"
42
As other said, for a single function accepting no arguments and returning a
single value Cython may be an heavy tool, but I bet you can imagine more
complex situations...
ciao, lele.
--
nickname: Lele Gaifax | Quando vivrò di quello che ho pensato ieri
real: Emanuele Gaifas | comincerò ad aver paura di chi mi copia.
[email protected] | -- Fortunato Depero, 1929.
--
https://mail.python.org/mailman/listinfo/python-list
Re: Easiest way to access C module in Python
On 07/11/2017 12:14, Lele Gaifax wrote:
bartc writes:
But just staying with the "function with no arguments" for the minute (the
equivalent of Hello World for this exercise), how would it be done in
Cython? Would a working example be simple enough to show in a usenet post?
fred.c::
int fred(void) {
return 42;
}
life.pyx::
cdef extern:
int fred()
def life():
return fred()
setup.py::
from distutils.core import setup
from distutils.extension import Extension
from Cython.Build import cythonize
setup(
ext_modules = cythonize([Extension("life", ["life.pyx", "fred.c"])])
)
$ python setup.py build_ext --inplace
OK, thanks. Although when I get to this bit, my system still says:
17.297
Traceback (most recent call last):
File "setup.py", line 1, in
from distutils.core import setup
So obviously something is wrong with it, but I'll have to assume it
normally works.
Compiling life.pyx because it changed.
[1/1] Cythonizing life.pyx
running build_ext
building 'life' extension
creating build
creating build/temp.linux-x86_64-3.6
x86_64-linux-gnu-gcc -pthread -DNDEBUG -g -fwrapv -O2 -Wall -Wstrict-prototypes -g -fdebug-prefix-map=/build/python3.6-5reRaQ/python3.6-3.6.3=. -specs=/usr/share/dpkg/no-pie-compile.specs
-fstack-protector-strong -Wformat -Werror=format-security -Wdate-time
-D_FORTIFY_SOURCE=2 -fPIC -I/tmp/ct/include -I/usr/include/python3.6m -c
life.c -o build/temp.linux-x86_64-3.6/life.o
However, it doesn't look that simple a process, and it seems to solve a
different problem from the ctypes solution. That one took an EXISTING
function, already compiled and linked into a binary, and does not need
the C source nor need to compile it. Often, you will only have the
binary shared library anyway.
-I/tmp/ct/include -I/usr/include/python3.6m -c fred.c -o
build/temp.linux-x86_64-3.6/fred.o
OK, compiling fred.c. Is there a dependency on gcc too? This looks more
like makefile hell. People use languages like Python to get away from
this stuff.
x86_64-linux-gnu-gcc -pthread -shared -Wl,-O1 -Wl,-Bsymbolic-functions
-specs=/usr/share/dpkg/no-pie-link.specs -Wl,-z,relro
-specs=/usr/share/dpkg/no-pie-link.specs -Wl,-z,relro -g
-fdebug-prefix-map=/build/python3.6-5reRaQ/python3.6-3.6.3=.
-specs=/usr/share/dpkg/no-pie-compile.specs -fstack-protector-strong -Wformat
-Werror=format-security -Wdate-time -D_FORTIFY_SOURCE=2
build/temp.linux-x86_64-3.6/life.o build/temp.linux-x86_64-3.6/fred.o -o
/tmp/ct/life.cpython-36m-x86_64-linux-gnu.so
$ python -c "import life; print(life.life())"
42
As other said, for a single function accepting no arguments and returning a
single value Cython may be an heavy tool, but I bet you can imagine more
complex situations...
In my normal work, I'm calling C functions from interpreted code all the
time, just not in Python (example below sig).
It's not that complicated. With this Cython solution you have the .c
(which has to be compiled and linked using this process), you have .pyx,
whatever that is, you have .py which is not really Python, but has to be
processed as Cython, and then you have .py which is actual Python, which
is the code that wanted to call that C function in the first. So simple.
I understand that Cython lets you write Python-like code with special
annotations that allows it to be compiled to efficient native code (or
something like that), but that's not what this task is, which is 100%
Python calling 100% C, with both developed using their normal tools.
--
bartc
# in interpreted code, run as normal:
importdll jpeg =
clang function loadjpeg(string, ref int64, ref int64)ref byte
end
In C:
byte* loadjpeg(char* file, int64* width, int64* height) {...
--
https://mail.python.org/mailman/listinfo/python-list
Re: I am trying to delete duplicates but the job just finishes with an exit code 0
[email protected] wrote: > I am trying to delete duplicates but the job just finishes with an exit > code 0 and does not delete any duplicates. > > The duplicates for the data always exist in Column F and I am desiring to > delete the entire row B-I > > Any ideas? > > > import openpyxl > wb1 = openpyxl.load_workbook('C:/dwad/SWWA.xlsx') > ws1 = wb1.active # keep naming convention consistent > > values = [] > for i in range(2,ws1.max_row+1): > if ws1.cell(row=i,column=1).value in values: > #pass > #else: > values.append(ws1.cell(row=i,column=1).value) > > for value in values: > ws1.append([value]) append() will add even more duplicates to the sheet. If you do not care about cell styles you can create a new sheet and copy only unique values. A complete example: import openpyxl SOURCE_FILE = "duplicates.xlsx" DEST_FILE = "unique.xlsx" HEADER_COUNT = 1 KEY_COLUMNS = [1] # zero-based A=0, B=1, ... workbook = openpyxl.load_workbook(SOURCE_FILE) source_sheet = workbook.active dest_sheet = workbook.create_sheet() seen = set() for i, row in enumerate(source_sheet.values): if i < HEADER_COUNT: dest_sheet.append(row) else: key = tuple(row[i] for i in KEY_COLUMNS) print("row = %r, key = %r" %(row, key)) if key not in seen: print("adding row", row) seen.add(key) dest_sheet.append(row) workbook.save(DEST_FILE) > I have attempted to do this with openpyxl for an excel as well as other > methods (including csv though this deleted rows excessively). I find that hard to believe. If anything it should keep more rows as you compare whole lines, not just the columns you are interested in. > CSV: > with open('1.csv','r') as in_file, open('2.csv','w') as out_file: > seen = set() # set for fast O(1) amortized lookup > for line in in_file: > if line not in seen: > seen.add(line) > out_file.write(line) General remark: use the csv module in the standard library rather than trying to parse the records manually. -- https://mail.python.org/mailman/listinfo/python-list
Re: Easiest way to access C module in Python
On 07/11/2017 13:11, bartc wrote: $ python setup.py build_ext --inplace OK, thanks. Although when I get to this bit, my system still says: 17.297 Traceback (most recent call last): File "setup.py", line 1, in from distutils.core import setup Update: if I copy the relevant files to the actual Python directory (so running Python as 'python' rather than '\python34\python'), the problem seems to be simply: ImportError: No module named 'Cython' (And trying script\pip install cython generated some promising disk activity for about a minute but then loads of errors, although no definitive message about whether it installed Cython or not. But since it still can't import the Cython module, I guess it didn't.) -- bartc -- https://mail.python.org/mailman/listinfo/python-list
Re: Easiest way to access C module in Python
bartc writes: > OK, compiling fred.c. Is there a dependency on gcc too? This looks more like > makefile hell. That's pretty standard distutils functionality. I'm pretty sure that on M$Windows it would invoke its C compiler, not gcc. I wrote "fred.c" to get closer to the case you mentioned, but obviously that function can very well come from a library. > People use languages like Python to get away from this stuff. Which people? The OP explicitly asked for a way to access a C module from Python, and Cython surely is one option to accomplish that. ciao, lele. -- nickname: Lele Gaifax | Quando vivrò di quello che ho pensato ieri real: Emanuele Gaifas | comincerò ad aver paura di chi mi copia. [email protected] | -- Fortunato Depero, 1929. -- https://mail.python.org/mailman/listinfo/python-list
Re: Easiest way to access C module in Python
On 2017-11-07 12:53, bartc wrote: > Having > said that, I located pip.exe, trying typing 'pip install cffi' and it > seemed to be doing something but then failed with a bunch of errors.) So you're missing out on all of PyPI? That's tragic. You should really try to fix that. I'm sure people on this list will be happy to help if you start a new thread with some details of what is happening on your system. -- Thomas Jollans -- https://mail.python.org/mailman/listinfo/python-list
Re: Easiest way to access C module in Python
On 07/11/2017 13:30, Thomas Jollans wrote: On 2017-11-07 12:53, bartc wrote: Having said that, I located pip.exe, trying typing 'pip install cffi' and it seemed to be doing something but then failed with a bunch of errors.) So you're missing out on all of PyPI? That's tragic. You should really try to fix that. I'm sure people on this list will be happy to help if you start a new thread with some details of what is happening on your system. You've lost me. I had to look up pyPI and it's something to do with a Package Index. But I don't know how that relates to installing Cython. The problem with pip was in Py3.4. I also have Py3.6, and that didn't have pip at all. Or it is something that itself needs to be installed first? Or is pyPI a new thing that replaces it? I'm not a serious Python user so it's not worth the effort of going around in circles trying to get these things working. I remember how difficult it was to get Numpy going a couple of years back. If it's already built-in, then fine, but if not, forget it. But for me it doesn't matter. -- bartc -- https://mail.python.org/mailman/listinfo/python-list
Re: Easiest way to access C module in Python
On 07/11/2017 14:20, bartc wrote: On 07/11/2017 13:30, Thomas Jollans wrote: On 2017-11-07 12:53, bartc wrote: Having said that, I located pip.exe, trying typing 'pip install cffi' and it seemed to be doing something but then failed with a bunch of errors.) So you're missing out on all of PyPI? That's tragic. You should really try to fix that. I'm sure people on this list will be happy to help if you start a new thread with some details of what is happening on your system. You've lost me. I had to look up pyPI and it's something to do with a Package Index. But I don't know how that relates to installing Cython. Can I just step in now with my Moderator hat on and ask: please avoid a lengthy "educate Bart C about Python" thread. If anyone wants to take it up with him in private, that's up to you. But please leave it off the list / newsgroup. Thanks TJG -- https://mail.python.org/mailman/listinfo/python-list
Re: Easiest way to access C module in Python
On 07/11/2017 14:33, Tim Golden wrote: On 07/11/2017 14:20, bartc wrote: You've lost me. I had to look up pyPI and it's something to do with a Package Index. But I don't know how that relates to installing Cython. Can I just step in now with my Moderator hat on and ask: please avoid a lengthy "educate Bart C about Python" thread. If anyone wants to take it up with him in private, that's up to you. But please leave it off the list / newsgroup. Well, that's not going to work because my email is not valid. But I've already said I'm not interested, and this is anyway getting a long way from what the OP is trying to do. I've stated that ctypes is my preferred approach for that. However I doubt I'm the only one having trouble with these peripheral aspects, and a mention of such problems can help others, even if it's for reassurance that the problems are not their fault! (This of course doesn't apply to the expert contributors here.) -- bartc -- https://mail.python.org/mailman/listinfo/python-list
What happens to module's variables after a "from module import" ?
Hello Here is my module tmp.py: a=0 def test(): global a print(a) a+=1 If I import function "test" from module "tmp" with: from tmp import test it works test() 0 test() 1 But where variable "a" is located ? I can't find it anywhere Regards -- https://mail.python.org/mailman/listinfo/python-list
Re: What happens to module's variables after a "from module import" ?
On 7 November 2017 at 15:39, ast wrote: > Hello > > Here is my module tmp.py: > > a=0 > > def test(): >global a >print(a) >a+=1 > > If I import function "test" from module "tmp" with: > from tmp import test > > > it works > test() > > 0 test() > > 1 > > But where variable "a" is located ? I can't find it anywhere It's in the "tmp" module, where you defined it. But because you didn't ask for a reference to it in your import statement, it's not accessible to you[1]. Do import tmp print(tmp.a) and you can see it. Paul [1] Technically you can find it via the globals of the function test, as test.__globals__['a'], but if you understand how that works, you wouldn't have been asking the question in the first place :-) -- https://mail.python.org/mailman/listinfo/python-list
Re: Incomplete description using sqlite3
Am 06.11.2017 um 23:40 schrieb Skip Montanaro:
I'm using sqlite3 (2.6.0, SQLite version 3.13.0, Python 2.7.13) and
was hoping to introspect the types of a table using the cursor's
description attribute. PEP 249 states: "The first two items (name and
type_code) are mandatory..." I tried this query:
conn = sqlite3("/some/existing/database")
curs = conn.cursor()
curs.execute("select * from mytable limit 1")
curs.fetchall()
Looking at curs.description, I see that it contained a seven-element
tuple for each column, but only the first element (name) was non-None.
Even the type_code field (required, according to the PEP) was None. I
tried the same trick using pyodbc talking to SQL Server (select top(1)
* from mytable). It returned more useful information.
Did I go about things wrong with SQLite, or is the sqlite3 module (or
SQLite database underlying it) not capable enough?
Thx,
Skip
I'd suspect the explanation is here:
https://sqlite.org/datatype3.html
HTH
Sibylle
--
https://mail.python.org/mailman/listinfo/python-list
Re: What happens to module's variables after a "from module import" ?
ast wrote: > Hello > > Here is my module tmp.py: > > a=0 > > def test(): > global a > print(a) > a+=1 > > If I import function "test" from module "tmp" with: > from tmp import test > > it works > test() > 0 test() > 1 > > But where variable "a" is located ? I can't find it anywhere The function keeps a reference to the global namespace of the tmp module. >>> from tmp import test >>> test.__globals__["a"] 0 >>> test() 0 >>> test.__globals__["a"] 1 The module is cached; thus a subsequent import gives the same function and of course accesses the same global namespace: >>> from tmp import test as test2 >>> test is test2 True >>> test2() 1 When you remove the module from the cache (usually a bad idea, done here for demonstration purposes) you will get a new function and a new global namespace: >>> import sys >>> del sys.modules["tmp"] >>> from tmp import test as test3 >>> test is test3 False >>> test() 2 >>> test3() 0 -- https://mail.python.org/mailman/listinfo/python-list
Re: What happens to module's variables after a "from module import" ?
"Paul Moore" a écrit dans le message de news:[email protected]... On 7 November 2017 at 15:39, ast wrote: It's in the "tmp" module, where you defined it. But because you didn't ask for a reference to it in your import statement, it's not accessible to you[1]. Do import tmp print(tmp.a) and you can see it. Paul [1] Technically you can find it via the globals of the function test, as test.__globals__['a'], but if you understand how that works, you wouldn't have been asking the question in the first place :-) Clear, ty -- https://mail.python.org/mailman/listinfo/python-list
Re: Ideas about how software should behave (was: replacing `else` with `then` in `for` and `try`)
On Fri, Nov 3, 2017 at 11:55 PM, Ben Finney wrote: > Ian Kelly writes: > >> Please stop defending the use of incivility on this list. > > Please stop conflating people, who deserve civility, with ideas. We must > not allow the civility deserved by people, to prevent us from > criticising any ideas — especially not ideas about the behaviour of > software. No, I won't. I once believed this, too. I used it as a defense for criticism of religious ideas. "Oh, I'm not attacking the believers in religion. I'm attacking the *ideas* of religion." And I meant it, too: I wasn't *trying* to insult anybody when I would say that religious belief was foolish and ignorant. Nowadays I realize and accept that this is preposterous. You cannot criticize an idea without also criticizing the people who are attached to that idea. Even if no personal slight is intended, it is received that way. If your idea is bad, then by implication you are a person with bad ideas. Now, I'm not saying that we can't criticize ideas. We can, however, choose to be polite or not in how we go about it. -- https://mail.python.org/mailman/listinfo/python-list
Re: Ideas about how software should behave (was: replacing `else` with `then` in `for` and `try`)
On Sat, Nov 4, 2017 at 6:40 AM, Chris Angelico wrote:
> On Sat, Nov 4, 2017 at 11:25 PM, Jon Ribbens
> wrote:
>> On 2017-11-04, Ben Finney wrote:
>>> To respond to the criticism of an idea – criticism containing no mention
>>> of the person – as though it “clearly refers to the [person]”, is of
>>> significant concern on a software dicussion forum such as this.
>>
>> No, the thing that is "of significant conern on a software discussion
>> forum such as this" is people such as yourself defending the abuse of
>> other contributors.
>
> Maybe we're not defending the abuse of other contributors. Maybe we're
> defending a legitimate, if somewhat caustic, response to a ridiculous
> suggestion.
I don't think it was a ridiculous suggestion.
Assigment to False is a syntax error, even though it's lexically valid
and was accepted in the past.
Inconsistent indentation is a syntax error, even though it could be
parsed and has been in the past.
Wildcard imports inside a function are a syntax error, even though
it's lexically valid and mostly harmless.
Using "yield from" inside an async coroutine is a syntax error, even
though it's lexically valid and "await" and "yield from" are nearly
identical.
I haven't seen any argument against making "else" without "break" a
syntax error that wouldn't also apply to the above, with the exception
of Steve's manufactured interactive example ("manufactured" because
who really uses for-else interactively? If I really care that much
about output formatting I'm going to put it in a script). If there is
any extant code that would actually be broken by this, it's very
likely buggy.
--
https://mail.python.org/mailman/listinfo/python-list
Re: Easiest way to access C module in Python
On 11/06/2017 05:59 PM, Grant Edwards wrote: On 2017-11-06, John Pote wrote: I have successfully used Python to perform unit and integration tests in the past and I'd like to do the same for some C modules I'm working with at work. There seem to be a number of ways of doing this but being busy at work and home I looking for the approach with the least learning curve. When I want to test C modules (usually destined for an embedded system) using a Python framework, I use ctypes. https://docs.python.org/3/library/ctypes.html I'll second ctypes. It's pretty straightforward and I've made it do some very heavy lifting over the years. Cython is definitely more work. SWIG makes sense if you've got a huge number of interfaces you're trying to map and need to automate the process, but if you've got south of 20 I'd just do it natively with ctypes. -- Rob Gaddi, Highland Technology -- www.highlandtechnology.com Email address domain is currently out of order. See above to fix. -- https://mail.python.org/mailman/listinfo/python-list
Re: Easiest way to access C module in Python
Lele Gaifax wrote: $ python setup.py build_ext --inplace Compiling life.pyx because it changed. [1/1] Cythonizing life.pyx running build_ext building 'life' extension creating build creating build/temp.linux-x86_64-3.6 x86_64-linux-gnu-gcc -pthread -DNDEBUG -g -fwrapv -O2 -Wall -Wstrict-prototypes -g -fdebug-prefix-map=/build/python3.6-5reRaQ/python3.6-3.6.3=. -specs=/usr/share/dpkg/no-pie-compile.specs -fstack-protector-strong -Wformat -Werror=format-security -Wdate-time -D_FORTIFY_SOURCE=2 -fPIC -I/tmp/ct/include -I/usr/include/python3.6m -c life.c -o build/temp.linux-x86_64-3.6/life.o x86_64-linux-gnu-gcc -pthread -DNDEBUG -g -fwrapv -O2 -Wall -Wstrict-prototypes -g -fdebug-prefix-map=/build/python3.6-5reRaQ/python3.6-3.6.3=. -specs=/usr/share/dpkg/no-pie-compile.specs -fstack-protector-strong -Wformat -Werror=format-security -Wdate-time -D_FORTIFY_SOURCE=2 -fPIC -I/tmp/ct/include -I/usr/include/python3.6m -c fred.c -o build/temp.linux-x86_64-3.6/fred.o x86_64-linux-gnu-gcc -pthread -shared -Wl,-O1 -Wl,-Bsymbolic-functions -specs=/usr/share/dpkg/no-pie-link.specs -Wl,-z,relro -specs=/usr/share/dpkg/no-pie-link.specs -Wl,-z,relro -g -fdebug-prefix-map=/build/python3.6-5reRaQ/python3.6-3.6.3=. -specs=/usr/share/dpkg/no-pie-compile.specs -fstack-protector-strong -Wformat -Werror=format-security -Wdate-time -D_FORTIFY_SOURCE=2 build/temp.linux-x86_64-3.6/life.o build/temp.linux-x86_64-3.6/fred.o -o /tmp/ct/life.cpython-36m-x86_64-linux-gnu.so $ python -c "import life; print(life.life())" 42 I tried your example on Python 2.7 (Win-10 / MSVC), but failed: python.exe setup.py build_ext --inplace running build_ext building 'life' extension creating build creating build\temp.win32-2.7 creating build\temp.win32-2.7\Release f:\gv\VC_2017\VC\Tools\MSVC\14.11.25503\bin\HostX86\x86\cl.exe /c /nologo /Ox /MD /W3 /GS- /DNDEBUG -If:\ProgramFiler\Python27\include -If:\ProgramFiler\Python27\PC /Tclife.c /Fobuild\temp.win32-2.7\Release\life.obj life.c f:\gv\VC_2017\VC\Tools\MSVC\14.11.25503\bin\HostX86\x86\cl.exe /c /nologo /Ox /MD /W3 /GS- /DNDEBUG -If:\ProgramFiler\Python27\include -If:\ProgramFiler\Python27\PC /Tcfred.c /Fobuild\temp.win32-2.7\Release\fred.obj fred.c f:\gv\VC_2017\VC\Tools\MSVC\14.11.25503\bin\HostX86\x86\link.exe /DLL /nologo /INCREMENTAL:NO /LIBPATH:f:\ProgramFiler\Python27\libs /LIBPATH:f:\ProgramFiler\Python27\PCbuild /EXPORT:initlife build\temp.win32-2.7\Release\life.obj build\temp.win32-2.7\Release\fred.obj /OUT:F:\ProgramFiler\Python27\test\Cython-test2\life.pyd /IMPLIB:build\temp.win32-2.7\Release\life.lib /MANIFESTFILE:build\temp.win32-2.7\Release\life.pyd.manifest Creating library build\temp.win32-2.7\Release\life.lib and object build\temp.win32-2.7\Release\life.exp python.exe -c "import life; print(life.life())" Traceback (most recent call last): File "", line 1, in AttributeError: 'module' object has no attribute 'life' Can you give a hint? -- --gv -- https://mail.python.org/mailman/listinfo/python-list
Re: Easiest way to access C module in Python
Gisle Vanem writes:
> python.exe -c "import life; print(life.life())"
> Traceback (most recent call last):
> File "", line 1, in
> AttributeError: 'module' object has no attribute 'life'
>
> Can you give a hint?
I tried with Python 2, and the same recipe works for me, on GNU/Linux:
$ python -c "import life; print life.life()"
42
I'm sorry, but I have no opportunity to try on a M$Windows system.
Anyway, is your interpreter able to load the extension module produced by the
"setup.py build_ext" step?
On my PC, I get the following, using the "-v" option to verbosely see the
imported modules:
$ $ python -v
# installing zipimport hook
import zipimport # builtin
# installed zipimport hook
...
>>> import life
dlopen("./life.so", 2);
import life # dynamically loaded from life.so
>>> dir(life)
['__builtins__', '__doc__', '__file__', '__name__', '__package__', '__test__',
'life']
Can you try to import the "life" module and print its "dir()" to see the
symbols it exposes?
ciao, lele.
--
nickname: Lele Gaifax | Quando vivrò di quello che ho pensato ieri
real: Emanuele Gaifas | comincerò ad aver paura di chi mi copia.
[email protected] | -- Fortunato Depero, 1929.
--
https://mail.python.org/mailman/listinfo/python-list
Re: Ideas about how software should behave (was: replacing `else` with `then` in `for` and `try`)
On Wed, Nov 8, 2017 at 4:28 AM, Ian Kelly wrote:
> On Sat, Nov 4, 2017 at 6:40 AM, Chris Angelico wrote:
>> On Sat, Nov 4, 2017 at 11:25 PM, Jon Ribbens
>> wrote:
>>> On 2017-11-04, Ben Finney wrote:
To respond to the criticism of an idea – criticism containing no mention
of the person – as though it “clearly refers to the [person]”, is of
significant concern on a software dicussion forum such as this.
>>>
>>> No, the thing that is "of significant conern on a software discussion
>>> forum such as this" is people such as yourself defending the abuse of
>>> other contributors.
>>
>> Maybe we're not defending the abuse of other contributors. Maybe we're
>> defending a legitimate, if somewhat caustic, response to a ridiculous
>> suggestion.
>
> I don't think it was a ridiculous suggestion.
>
> Assigment to False is a syntax error, even though it's lexically valid
> and was accepted in the past.
Assignment to None was and is a syntax error, and assignment to False
was legal only for backward compatibility within the 2.x line. I'm not
sure what your point is. None, False, and True are all keywords, not
built-ins, so you can't assign to them (any more than you could assign
to a literal integer).
> Inconsistent indentation is a syntax error, even though it could be
> parsed and has been in the past.
I'm not sure what you mean by "inconsistent" here, unless it's that
tabs and spaces had a declared equivalency that they now don't.
Unindenting to a level you've never used has always been an error;
being sloppy has never been:
if 1:
if 2:
pass
pass # always an error
if 3:
pass # never an error
Again, though, I'm not sure what your point is. Are you saying that it
was ridiculous (or called ridiculous) to separate tabs and spaces
rather than treat them as equivalent? Or are you saying that it ought
to be legal?
> Wildcard imports inside a function are a syntax error, even though
> it's lexically valid and mostly harmless.
Mostly harmless? Hmm. Okay:
def func1():
spam = 1
def func2():
from module import *
def func3():
nonlocal spam
spam += 1
What does func3's spam refer to?
I don't know for sure if that's why star imports got banned, but I
also don't know for sure what should happen in the above situation
either.
> Using "yield from" inside an async coroutine is a syntax error, even
> though it's lexically valid and "await" and "yield from" are nearly
> identical.
I'm not sure about this one, but the equivalence of await and yield
from is a red herring. The part that's more surprising is this:
>>> async def foo():
...yield from [1,2,3]
...
File "", line 2
SyntaxError: 'yield from' inside async function
>>> async def foo():
...for _ in [1,2,3]: yield _
...
(Yes, I know "yield from" does a lot more than "for... yield" does)
But in comparison to "for... break", this is definitely not an error
on the basis that it "makes no sense". It's more likely to be an error
because of some internal limitation, in the same way that async
coroutines weren't possible _at all_ initially:
Python 3.5.3 (default, Jan 19 2017, 14:11:04)
[GCC 6.3.0 20170118] on linux
Type "help", "copyright", "credits" or "license" for more information.
>>> async def foo(): yield 1
...
File "", line 1
SyntaxError: 'yield' inside async function
That's no longer a SyntaxError as of 3.6, and I suspect that making
"yield from" work inside an async function is, if not actually on the
roadmap, certainly a possibility.
> I haven't seen any argument against making "else" without "break" a
> syntax error that wouldn't also apply to the above, with the exception
> of Steve's manufactured interactive example ("manufactured" because
> who really uses for-else interactively? If I really care that much
> about output formatting I'm going to put it in a script). If there is
> any extant code that would actually be broken by this, it's very
> likely buggy.
There are many MANY constructs that are broadly useless.
Global declaration without assignment:
>>> def foo():
... global print
... print("hello")
...
Unused variable (often indicates a misspelling):
>>> def bar():
... x = 1
... return y
...
Never-executed bodies:
>>> def spam():
... if False: print("ham")
... while False: print("ham")
... for _ in []: print("ham")
... try: pass
... except ZeroDivisionError: print("ham")
...
(In CPython 3.7, the optimizer will eliminate the first two, but not
the for or try. That could change, of course.)
Not one of these is syntactically invalid. Why should "else without
break" be trapped by the parser? Your other examples mostly have good
parser-level reasons for being errors (you could argue from a language
design POV about why False is a keyword but Ellipsis is just a
built-in, but it's obvious that assigning to keywords has to be an
error). Merely being pointless does not justify being an error;
*maybe* the language co
Re: Ideas about how software should behave
On 2017-11-07, Stefan Ram wrote: > Chris Angelico writes: >>sure what your point is. None, False, and True are all keywords, not >>built-ins, so you can't assign to them (any more than you could assign >>to a literal integer). > >|Python 2.6.6 (r266:84297, Aug 24 2010, 18:13:38) [MSC v.1500 64 bit (AMD64)] >on win32 >|Type "help", "copyright", "credits" or "license" for more information. >|>>> >|>>> import ctypes >|>>> >|>>> value = 2 >|>>> ob_ival_offset = ctypes.sizeof(ctypes.c_size_t) + >ctypes.sizeof(ctypes.c_voidp) >|>>> ob_ival = ctypes.c_int.from_address(id(value)+ob_ival_offset) >|>>> ob_ival.value = 3 >|>>> >|>>> print 2 >|3 I vaguely remember being able to do that in some implementations of FORTRAN yonks ago: subroutine foo(i) i = 3 end subroutine func [...] foo(2) write(*,*) 2 output would be: 3 -- Grant Edwards grant.b.edwardsYow! If I pull this SWITCH at I'll be RITA HAYWORTH!! gmail.comOr a SCIENTOLOGIST! -- https://mail.python.org/mailman/listinfo/python-list
Re: Ideas about how software should behave
On Wed, Nov 8, 2017 at 6:44 AM, Stefan Ram wrote: > Chris Angelico writes: >>sure what your point is. None, False, and True are all keywords, not >>built-ins, so you can't assign to them (any more than you could assign >>to a literal integer). > > |Python 2.6.6 (r266:84297, Aug 24 2010, 18:13:38) [MSC v.1500 64 bit (AMD64)] > on win32 > |Type "help", "copyright", "credits" or "license" for more information. > |>>> > |>>> import ctypes > |>>> > |>>> value = 2 > |>>> ob_ival_offset = ctypes.sizeof(ctypes.c_size_t) + > ctypes.sizeof(ctypes.c_voidp) > |>>> ob_ival = ctypes.c_int.from_address(id(value)+ob_ival_offset) > |>>> ob_ival.value = 3 > |>>> > |>>> print 2 > |3 That's still not assigning to a literal; that's mutating a cached object. There's a difference :) Also, once you start messing with ctypes like this, all language guarantees are out the window. ChrisA -- https://mail.python.org/mailman/listinfo/python-list
ANN: Wing Python IDE v. 6.0.8 released
Hi, We've just released Wing 6.0.8, a minor release that improves display of PEP 287 docstrings, fixes stability problems seen on Linux, fixes remote debugging of Django code, further improves remote development, adds some missing vi bindings, and makes about 30 other improvements. For details, see https://wingware.com/pub/wingide/6.0.8/CHANGELOG.txt Wing 6 is the latest major release in Wingware's family of Python IDEs, including Wing Pro, Wing Personal, and Wing 101. Wing 6 adds many new features, introduces a new annual license option for Wing Pro, and makes Wing Personal free. New Features in Wing 6 * Improved Multiple Selections: Quickly add selections and edit them all at once * Easy Remote Development: Work seamlessly on remote Linux, OS X, and Raspberry Pi systems * Debugging in the Python Shell: Reach breakpoints and exceptions in (and from) the Python Shell * Recursive Debugging: Debug code invoked in the context of stack frames that are already being debugged * PEP 484 and PEP 526 Type Hinting: Inform Wing's static analysis engine of types it cannot infer * Support for Python 3.6 and Stackless 3.4: Use async and other new language features * Optimized debugger: Run faster, particularly in multi-process and multi-threaded code * Support for OS X full screen mode: Zoom to a virtual screen, with auto-hiding menu bar * Added a new One Dark color palette: Enjoy the best dark display style yet * Updated French and German localizations: Thanks to Jean Sanchez, Laurent Fasnacht, and Christoph Heitkamp For a more detailed overview of new features see the release notice at https://wingware.com/news/2017-11-03 Annual License Option Wing 6 adds the option of purchasing a lower-cost expiring annual license for Wing Pro. An annual license includes access to all available Wing Pro versions while it is valid, and then ceases to function until it is renewed. Pricing for annual licenses is US$ 179/user for Commercial Use and US$ 69/user for Non-Commercial Use. Perpetual licenses for Wing Pro will continue to be available at the same pricing. The cost of extending Support+Upgrades subscriptions on Non-Commercial Use perpetual licenses for Wing Pro has also been dropped from US$ 89 to US$ 39 per user. For details, see https://wingware.com/store/ Wing Personal is Free Wing Personal is now free and no longer requires a license to run. It now also includes the Source Browser, PyLint, and OS Commands tools, and supports the scripting API and Perspectives. However, Wing Personal does not include Wing Pro's advanced editing, debugging, testing and code management features, such as remote development, refactoring, find uses, version control, unit testing, interactive debug probe, multi-process and child process debugging, move program counter, conditional breakpoints, debug watch, framework-specific support (for Jupyter, Django, and others), find symbol in project, and other features. Links Release notice: https://wingware.com/news/2017-11-03 Downloads and Free Trial: https://wingware.com/downloads Buy: https://wingware.com/store/purchase Upgrade: https://wingware.com/store/upgrade Questions? Don't hesitate to email us at [email protected]. Thanks, -- Stephan Deibel Wingware | Python IDE The Intelligent Development Environment for Python Programmers wingware.com -- https://mail.python.org/mailman/listinfo/python-list
Re: Easiest way to access C module in Python
Lele Gaifax wrote:
On my PC, I get the following, using the "-v" option to verbosely see the
imported modules:
$ $ python -v
# installing zipimport hook
import zipimport # builtin
# installed zipimport hook
...
import life
dlopen("./life.so", 2);
import life # dynamically loaded from life.so
dir(life)
['__builtins__', '__doc__', '__file__', '__name__', '__package__', '__test__',
'life']
Can you try to import the "life" module and print its "dir()" to see the
symbols it exposes?
From inside python 2.7:
Python 2.7.13rc1 (v2.7.13rc1:4d6fd49eeb14, Dec 3 2016, 21:49:42) [MSC v.1500
32 bit (Intel)] on win32
Type "help", "copyright", "credits" or "license" for more information.
>>> import life
>>> dir(life)
['__builtins__', '__doc__', '__file__', '__name__', '__package__', '__test__']
>>>
works fine. But as I wrote, doing a:
python -vc "import life; print(life.life())"
from the cmd-line doesn't work:
...
import life # dynamically loaded from life.pyd
Traceback (most recent call last):
File "", line 1, in
AttributeError: 'module' object has no attribute 'life'
...
Inspection life.pyd shows no problems. It do export a "initlife"
function.
--
--gv
--
https://mail.python.org/mailman/listinfo/python-list
Re: Ideas about how software should behave
On 2017-11-07, Chris Angelico wrote: > On Wed, Nov 8, 2017 at 6:44 AM, Stefan Ram wrote: >> Chris Angelico writes: >>>sure what your point is. None, False, and True are all keywords, not >>>built-ins, so you can't assign to them (any more than you could assign >>>to a literal integer). >> >> |Python 2.6.6 (r266:84297, Aug 24 2010, 18:13:38) [MSC v.1500 64 bit >> (AMD64)] on win32 >> |Type "help", "copyright", "credits" or "license" for more information. >> |>>> >> |>>> import ctypes >> |>>> >> |>>> value = 2 >> |>>> ob_ival_offset = ctypes.sizeof(ctypes.c_size_t) + >> ctypes.sizeof(ctypes.c_voidp) >> |>>> ob_ival = ctypes.c_int.from_address(id(value)+ob_ival_offset) >> |>>> ob_ival.value = 3 >> |>>> >> |>>> print 2 >> |3 > > That's still not assigning to a literal; that's mutating a cached > object. There's a difference :) True. > Also, once you start messing with ctypes like this, all language > guarantees are out the window. In FORTRAN, the only language gurantees were 1) When running your program, you'd almost, but not always, get all of your cards back. 2) The probability (P) of finding an available IBM 29 cardpunch was approximately D**2 where D is how many day's you had left before your deadline: with one hour left, P = 1/(24*24). -- Grant Edwards grant.b.edwards Yow! LOOK!! Sullen at American teens wearing gmail.com MADRAS shorts and "Flock of Seagulls" HAIRCUTS! -- https://mail.python.org/mailman/listinfo/python-list
Re: Easiest way to access C module in Python
On 07/11/2017 20:08, Gisle Vanem wrote:
Lele Gaifax wrote:
On my PC, I get the following, using the "-v" option to verbosely see the
imported modules:
$ $ python -v
# installing zipimport hook
import zipimport # builtin
# installed zipimport hook
...
import life
dlopen("./life.so", 2);
import life # dynamically loaded from life.so
dir(life)
['__builtins__', '__doc__', '__file__', '__name__', '__package__',
'__test__', 'life']
Can you try to import the "life" module and print its "dir()" to see the
symbols it exposes?
From inside python 2.7:
Python 2.7.13rc1 (v2.7.13rc1:4d6fd49eeb14, Dec 3 2016, 21:49:42)
[MSC v.1500 32 bit (Intel)] on win32
Type "help", "copyright", "credits" or "license" for more information.
>>> import life
>>> dir(life)
['__builtins__', '__doc__', '__file__', '__name__', '__package__',
'__test__']
>>>
works fine.
Not really, as it's missing the attribute 'life' which is needed for the
second part of 'life.life':
But as I wrote, doing a:
python -vc "import life; print(life.life())"
--
bartc
--
https://mail.python.org/mailman/listinfo/python-list
Re: Ideas about how software should behave (was: replacing `else` with `then` in `for` and `try`)
On Tue, Nov 7, 2017 at 12:10 PM, Chris Angelico wrote:
> On Wed, Nov 8, 2017 at 4:28 AM, Ian Kelly wrote:
>> On Sat, Nov 4, 2017 at 6:40 AM, Chris Angelico wrote:
>>> Maybe we're not defending the abuse of other contributors. Maybe we're
>>> defending a legitimate, if somewhat caustic, response to a ridiculous
>>> suggestion.
>>
>> I don't think it was a ridiculous suggestion.
>>
>> Assigment to False is a syntax error, even though it's lexically valid
>> and was accepted in the past.
>
> Assignment to None was and is a syntax error, and assignment to False
> was legal only for backward compatibility within the 2.x line. I'm not
> sure what your point is. None, False, and True are all keywords, not
> built-ins, so you can't assign to them (any more than you could assign
> to a literal integer).
That's a false equivalence. There is nothing about None, False or True
that *requires* them to be keywords, and my point is that in Python 2,
two out of the three were *not* keywords. Making them keywords was a
backward-incompatible change and entirely unnecessary, but it was done
because it was deemed to be worthwhile.
>> Inconsistent indentation is a syntax error, even though it could be
>> parsed and has been in the past.
>
> I'm not sure what you mean by "inconsistent" here, unless it's that
> tabs and spaces had a declared equivalency that they now don't.
Yes.
> Unindenting to a level you've never used has always been an error;
> being sloppy has never been:
>
> if 1:
> if 2:
> pass
> pass # always an error
> if 3:
> pass # never an error
>
> Again, though, I'm not sure what your point is. Are you saying that it
> was ridiculous (or called ridiculous) to separate tabs and spaces
> rather than treat them as equivalent? Or are you saying that it ought
> to be legal?
No, my point is not about indentation. I listed these things as
examples of useful syntax errors that are not unlike the for-else
syntax error suggestion. In this case, the change to treat tabs and
spaces separately for indentation was a good one, albeit backward
incompatible, and the suggestion to disallow for-else without break is
likewise a good one, albeit backward incompatible.
>> Wildcard imports inside a function are a syntax error, even though
>> it's lexically valid and mostly harmless.
>
> Mostly harmless? Hmm. Okay:
>
> def func1():
> spam = 1
> def func2():
> from module import *
> def func3():
> nonlocal spam
> spam += 1
>
> What does func3's spam refer to?
In my opinion, it should refer to the variable from func1, since the
star import can't be assumed to introduce a "spam" variable, and it
doesn't make sense for the meaning of the code (and the generated byte
code content) to depend on whether it does.
> I don't know for sure if that's why star imports got banned, but I
> also don't know for sure what should happen in the above situation
> either.
I think it's more likely because fast locals don't support dynamic
modification, the same reason why a call to exec() from a function
body can't modify the local variables either. It's not that this is
technically infeasible; it's just unsupported.
>> Using "yield from" inside an async coroutine is a syntax error, even
>> though it's lexically valid and "await" and "yield from" are nearly
>> identical.
>
> I'm not sure about this one, but the equivalence of await and yield
> from is a red herring. The part that's more surprising is this:
>
async def foo():
> ...yield from [1,2,3]
> ...
> File "", line 2
> SyntaxError: 'yield from' inside async function
async def foo():
> ...for _ in [1,2,3]: yield _
> ...
>
> (Yes, I know "yield from" does a lot more than "for... yield" does)
>
> But in comparison to "for... break", this is definitely not an error
> on the basis that it "makes no sense". It's more likely to be an error
> because of some internal limitation, in the same way that async
> coroutines weren't possible _at all_ initially:
No, it isn't. They share implementation. The only difference between
the two apart from the syntactic restrictions is that await validates
the type of its argument and looks for a method called __await__
instead of __iter__; see PEP 492.
I suspect that the reason for the restriction was to reserve lexical
space for asynchronous generators to be supported in the future,
although PEP 525 only permits yield and not yield from, having
explicitly deferred yield from as "less critical" and "requiring
serious redesign".
>> I haven't seen any argument against making "else" without "break" a
>> syntax error that wouldn't also apply to the above, with the exception
>> of Steve's manufactured interactive example ("manufactured" because
>> who really uses for-else interactively? If I really care that much
>> about output formatting I'm going to put it in a script). If there is
>> any extant code that would actually be broken by this, it's very
>> likely buggy.
>
>
Re: Easiest way to access C module in Python
bartc wrote: From inside python 2.7: Python 2.7.13rc1 (v2.7.13rc1:4d6fd49eeb14, Dec 3 2016, 21:49:42) [MSC v.1500 32 bit (Intel)] on win32 Type "help", "copyright", "credits" or "license" for more information. >>> import life >>> dir(life) ['__builtins__', '__doc__', '__file__', '__name__', '__package__', '__test__'] >>> works fine. Not really, as it's missing the attribute 'life' which is needed for the second part of 'life.life': Not sure what happend there. All is working now. But as you stated, Cython is truly a "beast". But as I wrote to Lele privately, the main reason for the failure, was Cygwin's Python2.7 messing up. I invoked the build from a GNU-Makefile. Thus Cygwin's Python was picked up from /bin/bash instead of my regular Python on PATH. A real PITA. -- --gv -- https://mail.python.org/mailman/listinfo/python-list
Re: Ideas about how software should behave (was: replacing `else` with `then` in `for` and `try`)
On Wed, Nov 8, 2017 at 8:16 AM, Ian Kelly wrote: > All of these are things that a linter should probably catch and warn > about. If you had said that the break syntax suggestion was a good > idea but probably better suited as a linter warning than as a > SyntaxError integrated into the parser, then I would likely agree with > you. That's not what you said, though. You said the suggestion was > "ridiculous". Someone did mention linters at one point, and if I didn't explicitly agree, I certainly didn't disagree. Let me make my position clearer: The suggestion that these should be hard errors in the parser is ridiculous because it is not the parser's job to catch all bugs. Python is not intended to be that sort of language. It is the job of a linter to detect probable errors. >> Not one of these is syntactically invalid. Why should "else without >> break" be trapped by the parser? Your other examples mostly have good >> parser-level reasons for being errors > > No, they don't. All four of them could just as easily also be accepted > by the parser and only flagged as linter warnings. If everyone in the world agreed that a tab was equal to eight spaces, then I would agree that the tab/space discrepancy could be considered a linter warning. But there's no such agreement, which means that having the language declare some equivalency is extremely dangerous. Py2 had several language features and misfeatures that are that dangerous (having the simple name "input()" do evaluation is a trap that MANY people have fallen into), and it's correct to fix that. If Python had, from the start, treated tabs and spaces as different forms of indentation, there would be no reason to change that now. Whether True and False are keywords or builtins is a matter of debate, but there are definite advantages to them being locked down, and the only real disadvantage that I see is the question of consistency (eg "Ellipsis" is not a keyword, so you can still assign to that). Having star imports be bypassed when looking for nonlocals is going to be extremely confusing if you DO import a name from the other module. There's no right answer to the nonlocal lookup question, so the best thing to do is to not permit it. There's fundamentally no way for this to be both legal and sane in all situations, so it can't be left up to the linter. Mixing 'async def' and 'yield from' is, AIUI, more of a NotImplementedError than a SyntaxError; the wording of the PEP basically says that it's low priority, not that it's a bad thing. So that one is never going to be flagged by a linter - once it's made possible, it'll be the normal and expected behaviour, so there's no reason to flag it (except perhaps as "beware that this is not backward compatible with Python <3.8"). So, no, this is not the same. ChrisA -- https://mail.python.org/mailman/listinfo/python-list
Re: Ideas about how software should behave
Ian Kelly writes: > Nowadays I realize and accept that this is preposterous. You cannot > criticize an idea without also criticizing the people who are attached > to that idea. Maybe so. Does that mean we must not criticise ideas? Later in your message you say no, but everything leading up to it argues you think so. In the thread which spawned this one, an idea was criticised, *because* someone expressed attachment to the idea. The idea was expressly one about software behaviour. Should that idea not be criticised in this forum, because someone expressed attachment to the idea? Does this forum allow ideas to be criticised only if no-one is attached to them? > Even if no personal slight is intended, it is received that way. If > your idea is bad, then by implication you are a person with bad ideas. Yes. And people with bad ideas rarely abandon bad ideas if those ideas are not shown to be bad. > Now, I'm not saying that we can't criticize ideas. We can, however, > choose to be polite or not in how we go about it. Certainly. It is incivil to make personal attacks. The criticism which started this sub-thread made no personal attack. Yet you've already pointed out that criticism of an idea – an idea specifically about how software should behave – is *perceived as* an attack, by people who are attached to the idea. You called such criticism “incivility”; presumably on the basis that the person was attached to the idea that was criticised. By responding, in this forum, to criticism of ideas with the admonishment of “incivility”, you effectively imply that it is incivil to criticise ideas strongly held — even when those ideas are about the behaviour of Python software, in a forum whose purpose is discussion of Python software. This is the condescension of low expectation: that someone who is attached to an idea deserves *less respect*, that they should not be exposed to criticism of ideas they hold lest they perceive it as an attack. That treats people as too fragile to examine an idea as separate from their person. I thoroughly reject that condescending attitude, and choose instead to promote respect that people *can* examine ideas when those ideas are criticised. Ideas, whether lightly or strongly held, are never immune from criticism. Indeed, for the purpose of reducing the amount of bad ideas held by people, those ideas must be criticised. Ideas about software behaviour, in this forum, are surely not an exception to that. -- \ “We jealously reserve the right to be mistaken in our view of | `\ what exists, given that theories often change under pressure | _o__) from further investigation.” —Thomas W. Clark, 2009 | Ben Finney -- https://mail.python.org/mailman/listinfo/python-list
Re: Ideas about how software should behave
On 11/7/17 5:48 PM, Ben Finney wrote: Ian Kelly writes: Nowadays I realize and accept that this is preposterous. You cannot criticize an idea without also criticizing the people who are attached to that idea. Maybe so. Does that mean we must not criticise ideas? Later in your message you say no, but everything leading up to it argues you think so. In the thread which spawned this one, an idea was criticised, *because* someone expressed attachment to the idea. The idea was expressly one about software behaviour. Should that idea not be criticised in this forum, because someone expressed attachment to the idea? Does this forum allow ideas to be criticised only if no-one is attached to them? Even if no personal slight is intended, it is received that way. If your idea is bad, then by implication you are a person with bad ideas. Yes. And people with bad ideas rarely abandon bad ideas if those ideas are not shown to be bad. Now, I'm not saying that we can't criticize ideas. We can, however, choose to be polite or not in how we go about it. Certainly. It is incivil to make personal attacks. The criticism which started this sub-thread made no personal attack. Yet you've already pointed out that criticism of an idea – an idea specifically about how software should behave – is *perceived as* an attack, by people who are attached to the idea. You called such criticism “incivility”; presumably on the basis that the person was attached to the idea that was criticised. By responding, in this forum, to criticism of ideas with the admonishment of “incivility”, you effectively imply that it is incivil to criticise ideas strongly held — even when those ideas are about the behaviour of Python software, in a forum whose purpose is discussion of Python software. This is the condescension of low expectation: that someone who is attached to an idea deserves *less respect*, that they should not be exposed to criticism of ideas they hold lest they perceive it as an attack. That treats people as too fragile to examine an idea as separate from their person. I thoroughly reject that condescending attitude, and choose instead to promote respect that people *can* examine ideas when those ideas are criticised. Ideas, whether lightly or strongly held, are never immune from criticism. Indeed, for the purpose of reducing the amount of bad ideas held by people, those ideas must be criticised. Ideas about software behaviour, in this forum, are surely not an exception to that. All of this could have been avoided. Steve called an idea arrogant. Jon felt that Steve was calling him arrogant. If Steve had simply said, "I'm sorry, I didn't mean that to apply to you," we wouldn't be here now. Why is it so hard to treat people as if they mattered? People are so caught up in proving others wrong and themselves right, that just saying, "Sorry, I wasn't clear" feels like giving ground. We need more civil discussion, and less sniping. We're better than this. --Ned. -- https://mail.python.org/mailman/listinfo/python-list
Re: Ideas about how software should behave (was: replacing `else` with `then` in `for` and `try`)
On Wed, 8 Nov 2017 04:28 am, Ian Kelly wrote:
> Steve's manufactured interactive example ("manufactured" because
> who really uses for-else interactively? If I really care that much
> about output formatting I'm going to put it in a script).
Me. As I have said.
I really don't appreciate you implying that I'm lying about that.
As for the question of whether anyone else uses it... that depends on whether
there is anyone else:
- using the REPL in an exploratory manner
- entering loops with more than, say, two or three lines on the fly
- that requires an additional block that has to run after the loop, without a
pause for input
- and they don't realise this until after they've started typing the loop
(it's *exploratory* coding, which means sometimes you haven't thought things
through until after you start typing)
- AND they have the insight to realise that you can use an else block to
rescue the situation without having to re-enter the lines already entered.
Given how unfamiliar for...else is, it's probably only a small number of
people that meet *all* these conditions, especially the last. I fear that
most people wouldn't have the insight to realise that you can do this --
because they either don't know for...else at all, or they have the wrong
mental model for it, or they simply aren't good at thinking outside the box.
Who knows what other "thinking outside the box" uses for for...else with no
break there are? Where there is one, there are probably others. The point is,
if you require break and make the absence a syntax error, you rule them out.
As things are today, the for block and the else block are loosely coupled.
Apart from the requirement that else must immediately follow a for (or while)
block, the language doesn't *force* there to be any coupling between the for
block and the else block. We may consider them to be separate blocks, almost
unrelated in principle (if not in practice).
That has the conceptual advantage that we can teach, learn and think about the
for and else blocks as separate concepts, which allows us to reason about
them by composition:
- we can reason about the for block as iteration over a sequence;
- if we now add an else block after it, we don't have to revise our reasoning
about the for block, we simply add the else block after it.
Which is why I was able to think outside the box and realise I could rescue my
already-typed dozen line for loop by adding an else clause.
Whereas Jon's model requires us to change our understanding of the for block:
- we reason about the for block as iteration;
- if we then add an else block, we have to go back and re-interpret the for
block as some sort of metaphorical search, whether or not it actually is a
search, before we can think about the else block. Otherwise it doesn't make
sense in his model of "search, else if not condition leading to break".
In Jon's model, if we interpret else as "else no break", then we're also left
with the mystery of what happened to the "if break" clause.
--
Steve
“Cheer up,” they said, “things could be worse.” So I cheered up, and sure
enough, things got worse.
--
https://mail.python.org/mailman/listinfo/python-list
Re: Ideas about how software should behave (was: replacing `else` with `then` in `for` and `try`)
On Tue, Nov 7, 2017 at 4:28 PM, Steve D'Aprano
wrote:
> On Wed, 8 Nov 2017 04:28 am, Ian Kelly wrote:
>
>> Steve's manufactured interactive example ("manufactured" because
>> who really uses for-else interactively? If I really care that much
>> about output formatting I'm going to put it in a script).
>
> Me. As I have said.
>
> I really don't appreciate you implying that I'm lying about that.
Sorry, I wasn't aware that you had said that.
--
https://mail.python.org/mailman/listinfo/python-list
Re: python3 byte decode
Hi, On 5 November 2017 at 04:06, Cameron Simpson wrote: > On 04Nov2017 01:47, Chris Angelico wrote: >> >> On Fri, Nov 3, 2017 at 8:24 PM, Ali Rıza KELEŞ >> wrote: >>> >>> Yesterday, while working with redis, i encountered a strange case. >>> >>> I want to ask why is the following `True` >>> >>> ``` >>> "s" is b"s".decode() >>> ``` >>> >>> while the followings are `False`? >>> >>> ``` >>> "so" is b"so".decode() >>> "som" is b"som".decode() >>> "some" is b"some".decode() >>> ``` >>> >>> Or vice versa? >>> >>> I read that `is` compares same objects, not values. So my question is >>> why "s" and b"s".decode() are same objects, while the others aren't? >>> >>> My python version is 3.6.3. > For speed and memory reasons, Python notices small values of strings and > ints, and allocates them only once. So When your write: > > a = "s" > b = "s" > > Python will reuse the same str object for both. Because of this, not only is > "a == b" (i.e. they have the same value) but also "a is b" (a and b refer to > the same object). But this is not guarrenteed, and certainly for larger > values Python doesn't bother. Eg: Actually I guessed that it should be a caching mechanism or something like, but i was not sure since I do not know python internals in detail. >> You shouldn't be comparing string objects with 'is'. Sometimes two >> equal strings will be identical, and sometimes they won't. All you're >> seeing is that the interpreter happened to notice and/or cache this >> particular lookup. > > > To be more clear here, usually when humans say "identical" they mean having > exactly the same value or attributes. > Here, Chris means that the two strings are actually the same object rather > than two equivalent objects. "is" tests the former (the same object). "==" > is for testing the latter (the objects have the same value). Initially the 'is' compared returned value with None, I changed the code and it remained as is. After i have noticed this issue. Using `is` to compare with None is OK, isn't it? Cameron, Terry, Chris thanks for your replies in depth. - Ali Riza >> >> > > > a = "ghghghghghg" > b = "ghghghghghg" > > Here they will have the same value but be different objects. So "==" will > still return True, but "is" would return False. > > You should usually be using "==" to compare things. "is" has its place, but > it is usually not what you're after. > > In your example code, b"s".decode() returns the string value "s", and Python > is internally deciding to reuse the existing "s" from the left half of your > comparison. It can do this because strings are immutable. (For example, "+=" > on a string makes a new string). > > Hoping this is now more clear, > Cameron Simpson (formerly [email protected]) > -- > https://mail.python.org/mailman/listinfo/python-list -- -- Ali Rıza Keleş -- https://mail.python.org/mailman/listinfo/python-list
Re: python3 byte decode
On Wed, Nov 8, 2017 at 4:36 PM, Ali Rıza KELEŞ wrote: >> To be more clear here, usually when humans say "identical" they mean having >> exactly the same value or attributes. >> Here, Chris means that the two strings are actually the same object rather >> than two equivalent objects. "is" tests the former (the same object). "==" >> is for testing the latter (the objects have the same value). > > Initially the 'is' compared returned value with None, I changed the > code and it remained as is. After i have noticed this issue. > > Using `is` to compare with None is OK, isn't it? Yes, that's correct. None is a singleton, so you check for it by identity. There are other uses of identity checks, such as: if str is bytes: # we're running Python 2, so encode/decode appropriately if blah() is NotImplemented: # use a fallback But when you're working with strings or numbers, you'll generally want to use equality checks. ChrisA -- https://mail.python.org/mailman/listinfo/python-list
