This issue tracker has been migrated to GitHub, and is currently read-only.
For more information, see the GitHub FAQs in the Python's Developer Guide.

Author ezio.melotti
Recipients akitada, akoumjian, alex, amaury.forgeotdarc, belopolsky, davide.rizzo, eric.snow, ezio.melotti, georg.brandl, giampaolo.rodola, gregory.p.smith, jacques, jaylogan, jhalcrow, jimjjewett, loewis, mark, moreati, mrabarnett, nneonneo, pitrou, r.david.murray, ronnix, rsc, sjmachin, steven.daprano, stiv, timehorse, vbr, zdwiel
Date 2011-09-02.03:38:11
SpamBayes Score 1.0020157e-10
Marked as misclassified No
Message-id <1314934693.27.0.143552775936.issue2636@psf.upfronthosting.co.za>
In-reply-to
Content
Also note that some behaviors are not "old" or "compatible", but just different.  For example why inline flags should be the old (or new) behavior?  Or e.g. the behavior of version 2 but not 0 and 1?
Also what if I want zero-width splits but not nested sets and sets operations?  Or if I want inline flags but not zero-width splits?

A new set of "features" flags might be an alternative approach.  It will also make possible to add new features that are not backward compatible that can be turned on explicitly with their flag.

It would be fine for me if I had to turn on explicitly e.g. nested sets if/when I'll need to use them, and keep having the "normal" behavior otherwise.

OTOH there are three problems with these approach:
  1) it's not compatible with regex (I guess people will use the external module in Python <3.3 and the included one in 3.3+, probably expecting the same semantics).  This is also true with the OLD/COMPAT flag though;
  2) it might require other inline feature-flags;
  3) the new set of flags might be added to the other flags or be separate, so e.g. re.compile(pattern, flags=re.I|re.NESTEDSETS) or re.compile(pattern, flags=re.I, features=re.NESTEDSETS).  I'm not sure it's a good idea to add another arg though.

Matthew, is there a comprehensive list of all the bugfix/features that have a different behavior from re?
We should first check what changes are acceptable and what aren't, and depending on how many and what they are we can then decide what is the best approach (a catch-all flag or several flags to change the behavior, transition period + warning before setting it as default, etc.)
History
Date User Action Args
2011-09-02 03:38:13ezio.melottisetrecipients: + ezio.melotti, loewis, georg.brandl, gregory.p.smith, jimjjewett, sjmachin, amaury.forgeotdarc, belopolsky, pitrou, nneonneo, giampaolo.rodola, rsc, timehorse, mark, vbr, mrabarnett, jaylogan, akitada, moreati, steven.daprano, alex, r.david.murray, jacques, zdwiel, jhalcrow, stiv, davide.rizzo, ronnix, eric.snow, akoumjian
2011-09-02 03:38:13ezio.melottisetmessageid: <1314934693.27.0.143552775936.issue2636@psf.upfronthosting.co.za>
2011-09-02 03:38:12ezio.melottilinkissue2636 messages
2011-09-02 03:38:11ezio.melotticreate