[Python-Dev] The "humor" section of the website is a bit outdated...

2017-01-04 Thread Ryan Gonzalez
Ok, in advance, my apologies for probably sending this to the wrong mailing
list...

Anyway, the most holy page in the entire Python website, containing all
sorts of deadly and wicked items, seems to have gathered a couple pounds of
dust:

https://www.python.org/doc/humor/

And by "pounds of dust", I mean that 2 of the links don't work anymore:

http://quotations.amk.ca/python-quotes/

seems to have been down for at least 3 years; available from archive.org (
http://web.archive.org/web/2011175522/http://quotations.amk.ca/python-quotes/
)

The Python humor wiki page is also gone:

https://wiki.python.org/PythonHumor

Being that the primary purpose is for proposing additions to the humor
list, I don't think archive.org would be of much help for this one.

--
Ryan (ライアン)
Yoko Shimomura > ryo (supercell/EGOIST) > Hiroyuki Sawano >> everyone else
http://kirbyfan64.github.io/
___
Python-Dev mailing list
Python-Dev@python.org
https://mail.python.org/mailman/listinfo/python-dev
Unsubscribe: 
https://mail.python.org/mailman/options/python-dev/archive%40mail-archive.com


[Python-Dev] IRC logs via BotBot.me

2017-01-04 Thread INADA Naoki
Hi.

IRC #python-dev channel is nice place to know what happens recently.
But I can't log in always because I use only laptop PC.

I found BotBot.me seems nice IRC log service and used by some major channels.
https://botbot.me/

I wonder if #python-dev is logged by BotBot.me.

I'm sorry if it had rejected already.
___
Python-Dev mailing list
Python-Dev@python.org
https://mail.python.org/mailman/listinfo/python-dev
Unsubscribe: 
https://mail.python.org/mailman/options/python-dev/archive%40mail-archive.com


Re: [Python-Dev] IRC logs via BotBot.me

2017-01-04 Thread Senthil Kumaran
On Wed, Jan 4, 2017 at 3:27 PM, INADA Naoki  wrote:
> I wonder if #python-dev is logged by BotBot.me.
>
> I'm sorry if it had rejected already.

I don't think so, but channel ops could request it.

Also, I found (https://www.irccloud.com) to be helpful to look at IRC
logs when away. (You can also permanently stay connected for a paid
service, afaict, they have put some interesting work into IRC over
web).

-- 
Senthil
___
Python-Dev mailing list
Python-Dev@python.org
https://mail.python.org/mailman/listinfo/python-dev
Unsubscribe: 
https://mail.python.org/mailman/options/python-dev/archive%40mail-archive.com


Re: [Python-Dev] IRC logs via BotBot.me

2017-01-04 Thread Berker Peksağ
On Thu, Jan 5, 2017 at 2:27 AM, INADA Naoki  wrote:
> Hi.
>
> IRC #python-dev channel is nice place to know what happens recently.
> But I can't log in always because I use only laptop PC.
>
> I found BotBot.me seems nice IRC log service and used by some major channels.
> https://botbot.me/
>
> I wonder if #python-dev is logged by BotBot.me.
>
> I'm sorry if it had rejected already.

I'm using my personal VPS to stay online on Freenode. This looks like
a tooling issue on your end and it can be solved without introducing a
public logging service.

--Berker
___
Python-Dev mailing list
Python-Dev@python.org
https://mail.python.org/mailman/listinfo/python-dev
Unsubscribe: 
https://mail.python.org/mailman/options/python-dev/archive%40mail-archive.com


Re: [Python-Dev] The "humor" section of the website is a bit outdated...

2017-01-04 Thread Berker Peksağ
On Wed, Jan 4, 2017 at 10:59 PM, Ryan Gonzalez  wrote:
> Ok, in advance, my apologies for probably sending this to the wrong mailing
> list...

Hi,

https://github.com/python/pythondotorg/issues is a better place to
report content issues on python.org.

--Berker
___
Python-Dev mailing list
Python-Dev@python.org
https://mail.python.org/mailman/listinfo/python-dev
Unsubscribe: 
https://mail.python.org/mailman/options/python-dev/archive%40mail-archive.com


[Python-Dev] ctypes, memory mapped files and context manager

2017-01-04 Thread Hans-Peter Jansen
Hi,

first of all, sorry for being such a pest, but all former attempts to solve 
this issue on other fora has been grinding to a halt.

In short: I try to combine a context manager with ctypes structures on memory 
mapped files in order to manage huge binary files. (An approach, that performs 
great, while easy to use and keeping the resource usage low).

FWIW, the code is targeted for Linux environments running Python3.

The smallest script demonstrating the issue (thanks to Peter Otten):

import ctypes
import mmap

from contextlib import contextmanager

class T(ctypes.Structure):
_fields = [("foo", ctypes.c_uint32)]


@contextmanager
def map_struct(m, n):
m.resize(n * mmap.PAGESIZE)
yield T.from_buffer(m)

SIZE = mmap.PAGESIZE * 2
f = open("tmp.dat", "w+b")
f.write(b"\0" * SIZE)
f.seek(0)
m = mmap.mmap(f.fileno(), mmap.PAGESIZE)

with map_struct(m, 1) as a:
a.foo = 1
with map_struct(m, 2) as b:
b.foo = 2


resulting in:
$ python3 mmap_test.py 
Traceback (most recent call last):
  File "mmap_test.py", line 23, in 
with map_struct(m, 2) as b:
  File "/usr/lib64/python3.4/contextlib.py", line 59, in __enter__
return next(self.gen)
  File "mmap_test.py", line 12, in map_struct
m.resize(n * mmap.PAGESIZE)
BufferError: mmap can't resize with extant buffers exported.


Python2 does not crash, but that's a different story. What happens here is: 
the context manager variable "a" keeps a reference to a memory mapped area 
alive, that results in a unresizable and not properly closable mmap.

Right now, this rather ugly and error prone workaround must be used, that 
renders the purpose of the context manager ad absurdum:

with map_struct(m, 1) as a:
a.foo = 1
del a
with map_struct(m, 2) as b:
b.foo = 2
del b

In order to get this working properly, the ctypes mapping needs a method to 
free the mapping actively. E.g.:

@contextmanager
def map_struct(m, n):
m.resize(n * mmap.PAGESIZE)
yield T.from_buffer(m)
 T.unmap_buffer(m)

Other attempts with weakref and the like do not work due to the nature of the 
ctypes types.

My own investigations in the _ctypes module were unsuccessful so far.

Hopefully, somebody in the audience cares enough for this module in order to 
get this fixed up (or probably I'm missing something obvious..).

Any ideas are very much appreciated.

Pete
___
Python-Dev mailing list
Python-Dev@python.org
https://mail.python.org/mailman/listinfo/python-dev
Unsubscribe: 
https://mail.python.org/mailman/options/python-dev/archive%40mail-archive.com


Re: [Python-Dev] ctypes, memory mapped files and context manager

2017-01-04 Thread Nick Coghlan
On 5 January 2017 at 10:28, Hans-Peter Jansen  wrote:
> In order to get this working properly, the ctypes mapping needs a method to
> free the mapping actively. E.g.:
>
> @contextmanager
> def map_struct(m, n):
> m.resize(n * mmap.PAGESIZE)
> yield T.from_buffer(m)
>  T.unmap_buffer(m)
>
> Other attempts with weakref and the like do not work due to the nature of the
> ctypes types.

I don't know ctypes well enough myself to comment on the idea of
offering fully deterministic cleanup, but the closest you could get to
that without requiring a change to ctypes is to have the context
manager introduce a layer of indirection:

class _T_data(ctypes.Structure):
_fields = [("foo", ctypes.c_uint32)]

class T:
def __init__(self, buffer):
self.data = _T_data.from_buffer(buffer)
def close(self):
self.data = None

@contextmanager
def map_struct(m, n):
m.resize(n * mmap.PAGESIZE)
mapped = T(m)
try:
yield mapped
finally:
mapped.close()

Client code would then need to consistently access the struct through
the data attribute:

with map_struct(m, 1) as a:
a.data.foo = 1
with map_struct(m, 2) as b:
b.data.foo = 2

Something like http://wrapt.readthedocs.io/en/latest/wrappers.html#object-proxy
would let you make the indirection to a contained object transparent,
but as far as I can tell, wrapt doesn't currently support "closing" a
proxy by replacing the reference to the internal object with a
reference to None (adding that might be possible, but I don't
personally know wrapt well enough to guess the feasibility of doing
so).

Cheers,
Nick.

-- 
Nick Coghlan   |   ncogh...@gmail.com   |   Brisbane, Australia
___
Python-Dev mailing list
Python-Dev@python.org
https://mail.python.org/mailman/listinfo/python-dev
Unsubscribe: 
https://mail.python.org/mailman/options/python-dev/archive%40mail-archive.com


Re: [Python-Dev] SystemError: new style getargs format but argument is not a tuple

2017-01-04 Thread Terry Reedy

On 1/1/2017 6:40 PM, Serhiy Storchaka wrote:

On 02.01.17 01:23, Terry Reedy wrote:

There are several recent question on Stackoverflow about

SystemError: new style getargs format but argument is not a tuple


[snip]
Resulting from using 3rd party packages.


No one commenting has a clue.  Is message from Victor's new calling
code?  Was it backported to 2.7?  Could error be a result of running old
3rd party binary that needs to be recompiled?


A system error "new style getargs format but argument is not a tuple" is
not new. It means that PyArg_ParseTuple() is called with not a tuple as
the first arguments. This is just a programmical error in third-party
extension.


Should the advice in the doc entry for SystemError be changed to include 
this case?


"You should report this to the author or maintainer of your Python 
interpreter. Be sure to report the version of the Python interpreter 
(sys.version; it is also printed at the start of an interactive Python 
session), the exact error message (the exception’s associated value) and 
if possible the source of the program that triggered the error.

"

--
Terry Jan Reedy


___
Python-Dev mailing list
Python-Dev@python.org
https://mail.python.org/mailman/listinfo/python-dev
Unsubscribe: 
https://mail.python.org/mailman/options/python-dev/archive%40mail-archive.com