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
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 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 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 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 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
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
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
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
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
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
Python-Dev@python.org
http:
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
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
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
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
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.
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
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
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 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 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 Wed, Jun 19, 2013 at 11:20 PM, senthil.kumaran <
python-check...@python.org> 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
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
Python-Dev@python.org
http://mail.python.org/mailman/listinfo/python-dev
Unsubscribe:
http://mail.python.org/mailm
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
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
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
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
> 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
Python-Dev@python.org
http://mail.p
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
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
> * 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*
>
31 matches
Mail list logo
