> * Add new GIL-free (no need to hold the GIL) memory allocator functions:
>
> - ``void* PyMem_RawMalloc(size_t size)``
> - ``void* PyMem_RawRealloc(void *ptr, size_t new_size)``
> - ``void PyMem_RawFree(void *ptr)``
> - the behaviour of requesting zero bytes is not defined: return *NULL*
>
Oh, please don't misunderstand. I'm not making any demands or requirements,
what I'm trying to do is to make recommendations based on experience that I
have had with embedding. This sound altogether too much like I'm trying to
push things one way or the other :)
The api as laid out certainly s
Hi,
I changed the PEP 445 according to the discussing on python-dev.
Read it online:
http://www.python.org/dev/peps/pep-0445/
Changes:
* add PyMemAllocatorDomain enum: PYALLOC_PYMEM_RAW, PYALLOC_PYMEM or
PYALLOC_PYOBJECT
* rename:
- PyMemBlockAllocator structure => PyMemAllocator
- PyM
> I also updated the implementation attached to:
> http://bugs.python.org/issue3329
I excluded new enums, structures and functions from the stable ABI,
except PyMem_Raw*() functions.
Victor
___
Python-Dev mailing list
[email protected]
http://mail.p
Le Thu, 20 Jun 2013 13:26:52 +0200,
Victor Stinner a écrit :
> Hi,
>
> I changed the PEP 445 according to the discussing on python-dev.
>
> Read it online:
> http://www.python.org/dev/peps/pep-0445/
>
> Changes:
>
> * add PyMemAllocatorDomain enum: PYALLOC_PYMEM_RAW, PYALLOC_PYMEM or
> PYALL
On 20 June 2013 15:37, Victor Stinner wrote:
> Le jeudi 20 juin 2013, Nick Coghlan a écrit :
>>
>> > Is PyMemMappingAllocator complete enough for your usage at CCP Games?
>>
>> Can we go back to calling this the "Arena" allocator? Or at least
>> "Mapped"? When I see "Mapping" in the context of Pyt
Hello,
I have re-implemented the entire stat module in C. [1] It's a necessary
step to fix portability issues. For most constants POSIX standards
dictate only the name of the constant and its meaning but not its value.
Only the values of permission bits (0644 == rw-r--r--) have fixed values.
For
we already have "_pyio.py", we could have "_pystat.py".
my 2c
--
Florent Xicluna
2013/6/20 Christian Heimes :
> Hello,
>
> I have re-implemented the entire stat module in C. [1] It's a necessary
> step to fix portability issues. For most constants POSIX standards
> dictate only the name of the c
Am 20.06.2013 15:21, schrieb Florent:
> we already have "_pyio.py", we could have "_pystat.py".
Works for me.
___
Python-Dev mailing list
[email protected]
http://mail.python.org/mailman/listinfo/python-dev
Unsubscribe:
http://mail.python.org/mailm
On Wed, Jun 19, 2013 at 11:20 PM, senthil.kumaran <
[email protected]> wrote:
> http://hg.python.org/cpython/rev/dfead0696a71
> changeset: 84224:dfead0696a71
> branch: 3.3
> parent: 84221:0113247f894b
> user:Senthil Kumaran
> date:Wed Jun 19 22:19:46 2013 -050
On 20 June 2013 22:16, Antoine Pitrou wrote:
> Le Thu, 20 Jun 2013 13:26:52 +0200,
> Victor Stinner a écrit :
>
>> Hi,
>>
>> I changed the PEP 445 according to the discussing on python-dev.
>>
>> Read it online:
>> http://www.python.org/dev/peps/pep-0445/
>>
>> Changes:
>>
>> * add PyMemAllocato
On 20 June 2013 23:29, Christian Heimes wrote:
> Am 20.06.2013 15:21, schrieb Florent:
>> we already have "_pyio.py", we could have "_pystat.py".
>
> Works for me.
I suggest following the guidelines in PEP 399 for cross implementation
compatibility of the standard library:
http://www.python.org/d
On 6/20/2013 9:40 AM, Nick Coghlan wrote:
> On 20 June 2013 23:29, Christian Heimes wrote:
>> Am 20.06.2013 15:21, schrieb Florent:
>>> we already have "_pyio.py", we could have "_pystat.py".
>>
>> Works for me.
>
> I suggest following the guidelines in PEP 399 for cross implementation
> compatib
On Thu, Jun 20, 2013 at 8:01 AM, Brett Cannon wrote:
>
>
>
> On Thu, Jun 20, 2013 at 10:14 AM, Eric V. Smith wrote:
>
>> On 6/20/2013 9:40 AM, Nick Coghlan wrote:
>> > On 20 June 2013 23:29, Christian Heimes wrote:
>> >> Am 20.06.2013 15:21, schrieb Florent:
>> >>> we already have "_pyio.py", we
2013/6/20 Thomas Wouters :
> If the .py file is going to be wrong or incomplete, why would we want to
> keep it -- or use it as fallback -- at all? If we're dead set on having a
> .py file instead of requiring it to be part of the interpreter (whichever
> that is, however it was built), it should b
cffi makes this kind of constant-grabbing very easy. However this is a
tiny module so no problem with having a C version.
On Thu, Jun 20, 2013 at 11:04 AM, Thomas Wouters wrote:
>
>
>
> On Thu, Jun 20, 2013 at 8:01 AM, Brett Cannon wrote:
>>
>>
>>
>>
>> On Thu, Jun 20, 2013 at 10:14 AM, Eric V.
On Thu, Jun 20, 2013 at 10:14 AM, Eric V. Smith wrote:
> On 6/20/2013 9:40 AM, Nick Coghlan wrote:
> > On 20 June 2013 23:29, Christian Heimes wrote:
> >> Am 20.06.2013 15:21, schrieb Florent:
> >>> we already have "_pyio.py", we could have "_pystat.py".
> >>
> >> Works for me.
> >
> > I suggest
2013/6/20 Charles-François Natali :
> 2013/6/20 Thomas Wouters :
>> If the .py file is going to be wrong or incomplete, why would we want to
>> keep it -- or use it as fallback -- at all? If we're dead set on having a
>> .py file instead of requiring it to be part of the interpreter (whichever
>> t
Am 20.06.2013 17:35, schrieb Benjamin Peterson:
> 2013/6/20 Charles-François Natali :
>> 2013/6/20 Thomas Wouters :
>>> If the .py file is going to be wrong or incomplete, why would we want to
>>> keep it -- or use it as fallback -- at all? If we're dead set on having a
>>> .py file instead of requ
20.06.13 16:05, Christian Heimes написав(ла):
I have re-implemented the entire stat module in C. [1] It's a necessary
step to fix portability issues. For most constants POSIX standards
dictate only the name of the constant and its meaning but not its value.
Only the values of permission bits (064
Review and comments on the ticket needed, please.
http://bugs.python.org/issue18244#msg191535
--
Best regards,
Łukasz Langa
WWW: http://lukasz.langa.pl/
Twitter: @llanga
IRC: ambv on #python-dev
___
Python-Dev mailing list
[email protected]
http:
2013/6/20 Serhiy Storchaka
> Now with enumerations in the stdlib the stat module constants are
> candidates for flag enumerations. How easy will be implement it on C?
Aha. Should an internal C module fetch the value of the constants, and a
public stat.py nicely wrap them in enums?
--
Amaury
But aren't most of these masks? enum,IntEnum doesn't handle those very
gracefully (the | operator returns a plain int).
On Thu, Jun 20, 2013 at 1:18 PM, Amaury Forgeot d'Arc
wrote:
> 2013/6/20 Serhiy Storchaka
>>
>> Now with enumerations in the stdlib the stat module constants are
>> candidates
On 06/20/2013 01:18 PM, Amaury Forgeot d'Arc wrote:
2013/6/20 Serhiy Storchaka wrote:
Now with enumerations in the stdlib the stat module constants are candidates
for flag enumerations. How easy will be
implement it on C?
Aha. Should an internal C module fetch the value of the constants, and
2013/6/20 Eric V. Smith >:
> But isn't the real problem with this module in Python the fact that the
> constants might be wrong? I'm not sure what, if anything, we can do
> about that.
Python is providing a stat module implemented in Python since 10 years, or
maybe 20 years, and I don't remember t
2013/6/20 Antoine Pitrou >:
> Victor Stinner > a écrit :
>> Changes:
>>
>> * add PyMemAllocatorDomain enum: PYALLOC_PYMEM_RAW, PYALLOC_PYMEM or
>> PYALLOC_PYOBJECT
>
> PYMEM_DOMAIN_RAW?
I prefer your suggestion because it shares the PYMEM/PyMem prefix with
PyMem_SetAllocator().
So the whole list
On 6/20/2013 4:53 PM, Victor Stinner wrote:
> 2013/6/20 Eric V. Smith >:
>> But isn't the real problem with this module in Python the fact that the
>> constants might be wrong? I'm not sure what, if anything, we can do
>> about that.
>
> Python is providing a stat module implemented in Python sinc
2013/6/20 Eric V. Smith :
> This is serious, not argumentative: If there's really no concern that
> the values be correct, then why implement it in C?
I read again the issue. The problem is to add new flags. Current flags
(type: block device/symlink/..., file mode) are well defined and
portable, w
On 06/20/2013 01:27 PM, Guido van Rossum wrote:
On Thu, Jun 20, 2013 at 1:18 PM, Amaury Forgeot d'Arc wrote:
2013/6/20 Serhiy Storchaka wrote:
Now with enumerations in the stdlib the stat module constants are
candidates for flag enumerations. How easy will be implement it on C?
Aha. Should a
2013/6/20 Serhiy Storchaka :
> Now with enumerations in the stdlib the stat module constants are candidates
> for flag enumerations. How easy will be implement it on C?
Numerical values are less important than S_ISxxx() macros. Example:
#define S_ISDOOR(mode) (((mode)&0xF000) == 0xd000)
0
On 21 June 2013 01:04, Thomas Wouters wrote:
> If the .py file is going to be wrong or incomplete, why would we want to
> keep it -- or use it as fallback -- at all? If we're dead set on having a
> .py file instead of requiring it to be part of the interpreter (whichever
> that is, however it was
31 matches
Mail list logo
