Stefan Behnel added the comment:
The avoid rebuilding part doesn't seem to work for me. Source build currently
fails as follows:
/bin/mkdir -p Include
python ./Parser/asdl_c.py -h Include ./Parser/Python.asdl
# Substitution happens here, as the completely-expanded BINDIR
# is not available in
Eli Bendersky added the comment:
Stefan, you need to run `make touch` if you want to avoid rebuilding. See
#15964 for more details.
[all bots run `make touch` before building now]
--
___
Python tracker rep...@bugs.python.org
Eli Bendersky added the comment:
This is also described in the Dev Guide:
https://docs.python.org/devguide/setup.html
--
___
Python tracker rep...@bugs.python.org
http://bugs.python.org/issue19655
___
Stefan Behnel added the comment:
That fixes it. Thanks!
--
___
Python tracker rep...@bugs.python.org
http://bugs.python.org/issue19655
___
___
Python-bugs-list mailing
Roundup Robot added the comment:
New changeset b769352e2922 by Eli Bendersky in branch 'default':
Issue #19655: Replace the ASDL parser carried with CPython
http://hg.python.org/cpython/rev/b769352e2922
--
nosy: +python-dev
___
Python tracker
Changes by Eli Bendersky eli...@gmail.com:
--
resolution: - fixed
stage: patch review - resolved
status: open - closed
___
Python tracker rep...@bugs.python.org
http://bugs.python.org/issue19655
___
Roundup Robot added the comment:
New changeset 604e1b1a by Eli Bendersky in branch 'default':
Issue #19655: Add tests for the new asdl parser.
http://hg.python.org/cpython/rev/604e1b1a
--
___
Python tracker rep...@bugs.python.org
Eli Bendersky added the comment:
Nick, it shouldn't be hard to drop to 3.3, but I'm curious why would the 3.4
requirement break Fedora, or anything for that matter? Does Fedora regenerate
the C implementation of the AST for some reason on every build? AFAIU, building
Python from source with
Nick Coghlan added the comment:
It won't break the build, but requiring 3.4 to be installed (rather than
3.3) makes it more annoying for me (and other Fedora users) to work on the
compiler before F21 is released :)
--
___
Python tracker
Larry Hastings added the comment:
I was told to keep Argument Clinic compatible with 3.3. I think it's a good
idea for the tools to not require absolutely current Python. Would it be a big
deal to support 3.3?
--
___
Python tracker
Eli Bendersky added the comment:
Updated patch attached:
1. Python 3.3+ supported (I suspect 3.2 will work too)
2. Incorporated Serhiy's suggestions (thanks for the review!)
--
Added file: http://bugs.python.org/file34742/new-asdl-parser.issue19655.2.patch
Serhiy Storchaka added the comment:
Now make fails when system Python is older than 3.4.
--
___
Python tracker rep...@bugs.python.org
http://bugs.python.org/issue19655
___
Eli Bendersky added the comment:
On Fri, Apr 4, 2014 at 6:10 AM, Serhiy Storchaka rep...@bugs.python.orgwrote:
Serhiy Storchaka added the comment:
Now make fails when system Python is older than 3.4.
This is why the .h .c files are checked in - someone just building Python
doesn't need
Nick Coghlan added the comment:
IIRC, that discussion was just about Python 2 vs Python 3. Can we get the
AST rebuild requirement dropped back to python3 being 3.3+ for the time
being so we don't break Fedora?
--
___
Python tracker
Eli Bendersky added the comment:
Since there has mostly been support for this, I'll wait a couple more days and
commit it unless someones objects or asks for more time for review.
--
___
Python tracker rep...@bugs.python.org
Eli Bendersky added the comment:
Attaching patch that implements this. To make it easier, the patch only
replaces the ASDL parser - not touching anything else and leaving the output
intact.
With this patch applied, when the Makefile is rerun it regenerates the actual
AST code in:
Eli Bendersky added the comment:
There were no serious objections bar the pre-release timing. Now that we're
safely in 3.5 territory, can I go ahead and create a patch?
Note that for purposes of review, the Github project linked in the original
message is more convenient, IMHO
--
Benjamin Peterson added the comment:
It certainly seems more compact and simple that the current parser, so +1 from
me.
--
___
Python tracker rep...@bugs.python.org
http://bugs.python.org/issue19655
___
Changes by Raymond Hettinger raymond.hettin...@gmail.com:
--
nosy: +rhettinger
___
Python tracker rep...@bugs.python.org
http://bugs.python.org/issue19655
___
___
Raymond Hettinger added the comment:
+1 for moving this forward as early in the 3.5 cycle as possible.
--
___
Python tracker rep...@bugs.python.org
http://bugs.python.org/issue19655
___
Changes by Mark Lawrence breamore...@yahoo.co.uk:
--
nosy: -BreamoreBoy
___
Python tracker rep...@bugs.python.org
http://bugs.python.org/issue19655
___
___
Eric Snow added the comment:
The concern, as far as I understand it, is that any change might introduce
regressions or even new bugs in the next beta. Something like swapping out the
parser generator implementation isn't a bug fix, but it isn't a new language
(incl. stdlib) feature either.
Brett Cannon added the comment:
Let's just go with Eli's latest idea and just save it for 3.5 since it won't
make any visible improvement in 3.4.
--
___
Python tracker rep...@bugs.python.org
http://bugs.python.org/issue19655
Brett Cannon added the comment:
All code going into Python should be idiomatic unless it's meant to be released
externally and there are backwards-compatibility concerns. It's Eli's call as
to whether he wants to maintain a PyPI project for this after integration.
Points 2-4 are off-topic for
Eli Bendersky added the comment:
Does anyone have comments on the code or can I prepare a patch for default?
Would it make sense to wait with this until the 3.4 branch is created or can I
just commit to default? Note that this change is not a new feature and is
essentially a no-op as far as
Brett Cannon added the comment:
It's Larry's call in the end but I personally don't care either way, especially
since this isn't user-facing code.
--
___
Python tracker rep...@bugs.python.org
http://bugs.python.org/issue19655
Larry Hastings added the comment:
Are the generated files *byte for byte* the same as produced by the existing
parser generation process?
--
___
Python tracker rep...@bugs.python.org
http://bugs.python.org/issue19655
Eli Bendersky added the comment:
Larry Hastings added the comment:
Are the generated files *byte for byte* the same as produced by the
existing parser generation process?
Correct. The generator runs during the build (in the Makefile), but only if
the files were out-of-date. It takes
Changes by Serhiy Storchaka storch...@gmail.com:
--
nosy: +serhiy.storchaka
___
Python tracker rep...@bugs.python.org
http://bugs.python.org/issue19655
___
___
Larry Hastings added the comment:
The rule is, no new features. Bug and security fixes from now on.
It isn't always clear whether or not something is a new feature. In the case
of such ambiguity, the decision is up to the sole discretion of the release
manager.
If you seriously want to
Eli Bendersky added the comment:
On Sun, Nov 24, 2013 at 2:58 PM, Larry Hastings rep...@bugs.python.orgwrote:
Larry Hastings added the comment:
The rule is, no new features. Bug and security fixes from now on.
It isn't always clear whether or not something is a new feature. In the
case
anatoly techtonik added the comment:
+1 for initiative, points that are nice to be addressed are below.
1. Python 3.4 with modern idioms - too Python-specific code raises the
barrier. I'd prefer simplicity and portability over modernism. Like how hard is
it to port the parser into JS with
New submission from Eli Bendersky:
It was mentioned in one of the recent python-dev threads that making the Python
code-base simpler to encourage involvement of contributors is a goal, so I
figured this may be relevant.
I've recently written a new parser for the ASDL specification language
Changes by Eli Bendersky eli...@gmail.com:
--
nosy: +eric.snow
___
Python tracker rep...@bugs.python.org
http://bugs.python.org/issue19655
___
___
Python-bugs-list
Eli Bendersky added the comment:
FWIW, asdl_c.py could use some modernization, but I'll defer this to a later
cleanup in order to do things gradually.
The same can be said for the Makefile rules - they can be simpler and more
efficient (no need to invoke asdl_c / parse the ASDL twice, for
Larry Hastings added the comment:
A week before beta? How confident are you in this new parser?
--
nosy: +larry
___
Python tracker rep...@bugs.python.org
http://bugs.python.org/issue19655
___
Eli Bendersky added the comment:
Larry, ease your worries: note that I only tagged this on version 3.5!
That said, this parser runs during the build and produces a .h file and .c file
- these partake in the build; I verified that the generated code is *identical*
to before, so there's not
Mark Lawrence added the comment:
Are we at beta for 3.5 already? :)
--
nosy: +BreamoreBoy
___
Python tracker rep...@bugs.python.org
http://bugs.python.org/issue19655
___
Changes by Stefan Krah stefan-use...@bytereef.org:
--
nosy: +skrah
___
Python tracker rep...@bugs.python.org
http://bugs.python.org/issue19655
___
___
Python-bugs-list
Changes by Eric Snow ericsnowcurren...@gmail.com:
--
nosy: +benjamin.peterson
___
Python tracker rep...@bugs.python.org
http://bugs.python.org/issue19655
___
___
Benjamin Peterson added the comment:
We could take the opportunity to ast scripts to a Tools/ subdir. Then you could
use whatever it is test_tools.py uses.
--
___
Python tracker rep...@bugs.python.org
http://bugs.python.org/issue19655
41 matches
Mail list logo
