On 02.06.2012 02:37, Mark Lawrence wrote:
On 01/06/2012 18:27, Brett Cannon wrote:
About the only thing I can think of from the language summit that we
discussed doing for Python 3.3 that has not come about is accepting the
regex module and getting it into the stdlib. Is this still being worked
On 01.06.2012 19:33, Brett Cannon wrote:
Are these dead in the water or are we going to try to change our
release cycle? I'm just asking since 3.3 final is due out in about 3
months and deciding on this along with shifting things if we do make
a change could end up taking that long and I suspect
Hi
I was reading a bit about the regex module and I would like to present some
other solution into speeding up the re module for Python.
So, as a bit of background - pypy has a re compatible module. It's also
JITted and it's also exportable as a C library (that is a library you can
call from C wi
Am 03.06.12 13:22, schrieb "Martin v. Löwis":
> - Some contributors are worried about getting their contributions "out",
> and some core committers are worried that we get fewer contributions
> because of that.
>
> While I well recall the feeling of getting changes "out", the real
> conce
On Sun, Jun 3, 2012 at 7:49 AM, Maciej Fijalkowski wrote:
> Hi
>
> I was reading a bit about the regex module and I would like to present some
> other solution into speeding up the re module for Python.
>
> So, as a bit of background - pypy has a re compatible module. It's also
> JITted and it's a
On Sun, Jun 3, 2012 at 3:06 PM, Calvin Spealman wrote:
> On Sun, Jun 3, 2012 at 7:49 AM, Maciej Fijalkowski
> wrote:
> > Hi
> >
> > I was reading a bit about the regex module and I would like to present
> some
> > other solution into speeding up the re module for Python.
> >
> > So, as a bit of b
The embedded (in both senses of the term) use cases for CPython pretty much
kill the idea, I'm afraid.
Those cases are also one of the biggest question marks over incorporating
regex wholesale instead of incrementally updating the existing engine to
achieve feature parity.
Publishing such a JIT c
On Sun, Jun 3, 2012 at 3:46 PM, Nick Coghlan wrote:
> The embedded (in both senses of the term) use cases for CPython pretty
> much kill the idea, I'm afraid.
>
As I said it can (and should) definitely be optional.
> Those cases are also one of the biggest question marks over incorporating
> r
On the minus side, the JIT only works on x86 and x86_64, on the plus
side, since it's 100% API compatible, it can be used as a _xxx
speedup module relatively easy.
Do people have opinions?
The main concern for re is not speed, but functionality. The Python re
module needs to grow a number of fe
On Sun, Jun 3, 2012 at 5:21 PM, "Martin v. Löwis" wrote:
> On the minus side, the JIT only works on x86 and x86_64, on the plus
>> side, since it's 100% API compatible, it can be used as a _xxx
>> speedup module relatively easy.
>>
>> Do people have opinions?
>>
>
> The main concern for re is not
It seems that by moving to VS 2010, we have killed Windows 2000 support,
for the same reason VS 2012 would kill XP support: Windows 2000
apparently won't recognize the .exe files as executables anymore.
I haven't actually tested this: can somebody please confirm?
A year ago, Brian put a statement
On Jun 03, 2012, at 01:22 PM, Martin v. Löwis wrote:
>- Some people (Barry in particular) are in favor of timed releases.
> I don't know what the actual motivation for timed releases is, but
Timed releases in general can provide much better predictability for others
depending on those releases.
2012/6/3 Maciej Fijalkowski :
> Hi
>
> I was reading a bit about the regex module and I would like to present some
> other solution into speeding up the re module for Python.
IMO, the most important feature of the regex module is that it fixes
long standing bugs and includes long requested feature
On 6/3/2012 7:22 AM, "Martin v. Löwis" wrote:
On 01.06.2012 19:33, Brett Cannon wrote:
Are these dead in the water or are we going to try to change our
release cycle? I'm just asking since 3.3 final is due out in about 3
months and deciding on this along with shifting things if we do make
a chan
On 06/03/2012 08:32 AM, "Martin v. Löwis" wrote:
So I propose to just remove the claim from the PEP that 3.3 would
still be supported, and not go through any notification period.
Did you mean
s/3.3/Windows 2000/
?
//arry/
___
Python-Dev mailing
On 03.06.2012 18:18, Larry Hastings wrote:
On 06/03/2012 08:32 AM, "Martin v. Löwis" wrote:
So I propose to just remove the claim from the PEP that 3.3 would
still be supported, and not go through any notification period.
Did you mean
s/3.3/Windows 2000/
?
I meant "that 3.3 would suppo
On Fri, Jun 1, 2012 at 5:37 PM, Nick Coghlan wrote:
> ipaddress really made it in because I personally ran into the limitations
> of not having IP address support in the stdlib. I ended up doing quite a
> bit of prompting to ensure the process of cleaning up the API to modern
> stdlib standards d
Maciej Fijalkowski wrote:
> On Sun, Jun 3, 2012 at 5:21 PM, "Martin v. Löwis" wrote:
>
> > On the minus side, the JIT only works on x86 and x86_64, on the plus
> >> side, since it's 100% API compatible, it can be used as a _xxx
> >> speedup module relatively easy.
> >>
> >> Do people have opini
On Sun, Jun 3, 2012 at 9:22 PM, "Martin v. Löwis" wrote:
> On 01.06.2012 19:33, Brett Cannon wrote:
>>
>> Are these dead in the water or are we going to try to change our
>> release cycle? I'm just asking since 3.3 final is due out in about 3
>> months and deciding on this along with shifting thin
On Mon, Jun 4, 2012 at 7:02 AM, Nick Coghlan wrote:
> I think marking both as Rejected would be an accurate reflection of
> python-dev's collective opinion.
Slight correction: I think it would accurately reflect python-dev's
*divided* opinion, using the principle of "Status quo wins a
stalemate".
On Mon, Jun 4, 2012 at 6:25 AM, Gregory P. Smith wrote:
>
> On Fri, Jun 1, 2012 at 5:37 PM, Nick Coghlan wrote:
>>
>> ipaddress really made it in because I personally ran into the limitations
>> of not having IP address support in the stdlib. I ended up doing quite a bit
>> of prompting to ensure
Hi,
Le 02/06/2012 12:59, Christian Tismer a écrit :
> One urgent question: will this feature be backported to Python 2.7?
Features are never backported to the stable versions. virtualenv still
exists as a standalone project which is compatible with 2.7 though.
Regards
__
On Sun, Jun 3, 2012 at 2:38 PM, Nick Coghlan wrote:
> On Mon, Jun 4, 2012 at 6:25 AM, Gregory P. Smith wrote:
> >
> > On Fri, Jun 1, 2012 at 5:37 PM, Nick Coghlan wrote:
> >>
> >> ipaddress really made it in because I personally ran into the
> limitations
> >> of not having IP address support i
On Sun, Jun 3, 2012 at 3:33 AM, Christian Tismer wrote:
> As an old windows guy, I very much agree with Kristjan. The venv
> approach is great. Windows is just a quite weird situation to handle
> in some cases, and a super-simple way to get rid of *any* built-in behavior
> concerning setup would b
On 04.06.12 00:28, Nick Coghlan wrote:
...
Backwards compatibility constraints mean we simply can't do that.
However, as noted above, it may make sense to provide more ways for
embedding applications to selectively access the behaviour through the
C API.
Why that???
I don't see this.
If you hav
That last statement basically suggests that something like regex would
never be accepted until a CPython core developer was actually running
into pain with the many flaws in the re module (especially when it comes
to Unicode). I disagree with that.
Per the language summit, I think we need to jus
heh. indeed. regardless, the module is available on pypi whether it
goes in or not so we do at least have something to point people to when
they need more than the existing undermaintained re (sre) module.
I completely disagree that SRE is unmaintained. It has about monthly
commits to it, to
I apologise, "unmaintained" is too strong a word. I mean "lacking an owner
sufficiently confident in their authority and expertise and with sufficient
time and energy to add,or approve the addition of, substantial new features
which may require significant refactoring of internal details".
Perhaps
Gregory P. Smith wrote:
Per the language summit, I think we need to just do it. Put it in as re
and rename the existing re module to sre.
I thought that the plan was to put the regex module in as regex, leaving re
unchanged for backwards compatibility, with any backwards-incompatible
renami
On Mon, Jun 4, 2012 at 7:11 AM, Nick Coghlan wrote:
> On Mon, Jun 4, 2012 at 7:02 AM, Nick Coghlan wrote:
>> I think marking both as Rejected would be an accurate reflection of
>> python-dev's collective opinion.
>
> Slight correction: I think it would accurately reflect python-dev's
> *divided*
On 6/3/2012 5:02 PM, Nick Coghlan wrote:
The one thing I actually *would* like to see change is for the cadence
of *alpha* releases to be increased to match that of maintenance
releases (that is, I'd like to see Python 3.4a1 released at the same
time as Python 3.3.1: around 6 months after the re
31 matches
Mail list logo
