On 27 October 2017 at 18:17, Stefan Krah wrote:
> Victor wrote a patch and would like to avoid adding a (probably
> unnecessary)
> emulation function. I agree with that.
>
> So if any platform does not have some form of aligned_alloc(), please
> speak up.
>
I think Victor's suggested strategy in
* Guido van Rossum , 2017-10-27, 08:35:
The "why" question is not very interesting -- it probably wasn't in
PCRE and nobody was familiar with it when we moved off PCRE (maybe it
wasn't even in Perl at the time -- it was ~15 years ago).
Perl supports \G since v5.0, released in 1994.
PCRE suppor
We’ve made a small change to the PEP process which may affect readers of
python-list and python-ideas, so I’d like to inform you of it. This change was
made to PEP 1 and PEP 12.
PEPs must have a Post-History header which records the dates at which the PEP
is posted to mailing lists, in order t
> From this I understand that when using e.g. findall() it forces successive
> matches to be adjacent.
yes, I admit that this is a clearer description of what \G does. My
only defense is that I wrote my description when it was late. :)
I can only stress how useful it is, especially for debuggin
ACTIVITY SUMMARY (2017-10-20 - 2017-10-27)
Python tracker at https://bugs.python.org/
To view or respond to any of the issues listed below, click on the issue.
Do NOT respond to this message.
Issues counts and deltas:
open6260 ( +0)
closed 37377 (+59)
total 43637 (+59)
Open issues wi
Oh. Yes, that is being discussed about once a year two. It seems Matthew
isn't very interested in helping out with the port, and there are some
concerns about backwards compatibility with the `re` module. I think it
needs a champion!
On Fri, Oct 27, 2017 at 8:50 AM, Tim Peters wrote:
> Note that
Note that Matthew Barnett's `regex` module already supports \G, and a
great many other features that weren't around 15 years ago ;-) either:
https://pypi.python.org/pypi/regex/
I haven't followed this in detail. I'm just surprised once per year
that it hasn't been folded into the core ;-)
[
Great!
On Fri, Oct 27, 2017 at 8:27 AM, Barry Warsaw wrote:
> On Oct 27, 2017, at 00:12, Guido van Rossum wrote:
> >
> > Heh, you're right that was the reasoning. But I think python-list is
> much less valuable than python-ideas for PEP authors. So let's change it.
>
> Sounds good. I just want
The "why" question is not very interesting -- it probably wasn't in PCRE
and nobody was familiar with it when we moved off PCRE (maybe it wasn't
even in Perl at the time -- it was ~15 years ago).
I didn't understand your description of \G so I googled it and found a
helpful StackOverflow article:
On Oct 27, 2017, at 00:12, Guido van Rossum wrote:
>
> Heh, you're right that was the reasoning. But I think python-list is much
> less valuable than python-ideas for PEP authors. So let's change it.
Sounds good. I just want to make sure we keep python-dev in the loop.
This is a process chang
Barry Warsaw wrote:
> In fact, we come with plugins for mail-archive.com and MHonarc.
MHonarc output is nice, practically the same as pipermail:
https://lists.debian.org/debian-x/2010/12/threads.html
If it is possible to enable (and maintain!) a MHonarc archive with just blue
links along wi
Hello,
we want to add aligned versions of allocation functions to 3.7:
https://bugs.python.org/issue18835
C11 has aligned_alloc().
Linux, BSD, OSX, MSVC, Android all have either posix_memalign() or
_aligned_malloc().
Cygwin apparently has posix_memalign().
MinGW has:
https://github.
All,
perl has a regex assertion (\G) that allows multiple-match regular
expressions to be able to use the position of the last match. Perl's
documentation puts it this way:
\G Match only at pos() (e.g. at the end-of-match position of prior m//g)
Anyways, this is exceedingly powerful for matc
On Fri, 27 Oct 2017 11:31:04 +0200
Antoine Pitrou wrote:
> On Thu, 26 Oct 2017 15:42:19 -0700
> Ethan Smith wrote:
> > Stub Only Packages
> > ''
> >
> > For package maintainers wishing to ship stub files containing all of their
> > type information, it is prefered that the ``*.py
On Thu, 26 Oct 2017 15:42:19 -0700
Ethan Smith wrote:
> Stub Only Packages
> ''
>
> For package maintainers wishing to ship stub files containing all of their
> type information, it is prefered that the ``*.pyi`` stubs are alongside the
> corresponding ``*.py`` files. However, the
On Thu, Oct 26, 2017 at 3:42 PM, Ethan Smith wrote:
> However, the stubs may be put in a sub-folder
> of the Python sources, with the same name the ``*.py`` files are in. For
> example, the ``flyingcircus`` package would have its stubs in the folder
> ``flyingcircus/flyingcircus/``. This path is c
16 matches
Mail list logo
