Re: [Python-Dev] Any grammar experts?

[R. David Murray]

On Mon, 26 Jan 2015 01:21:24 +0100, Antoine Pitrou  wrote:
> On Sun, 25 Jan 2015 14:59:42 -0800
> Guido van Rossum  wrote:
> > On Sun, Jan 25, 2015 at 7:32 AM, Georg Brandl  wrote:
> > 
> > > On 01/25/2015 04:08 PM, Antoine Pitrou wrote:
> > > > On Sat, 24 Jan 2015 21:10:51 -0500
> > > > Neil Girdhar  wrote:
> > > >> To finish PEP 448, I need to update the grammar for syntax such as
> > > >>
> > > >> {**x for x in it}
> > > >
> > > > Is this seriously allowed by the PEP? What does it mean exactly?
> > >
> > > It appears to go a bit far.  Especially since you also would have to allow
> > >
> > > {*x for x in it}
> > >
> > > which is a set comprehension, while the other is a dict comprehension :)
> > >
> > 
> > That distinction doesn't bother me -- you might as well claim it's
> > confusing that f(*x) passes positional args from x while f(**x) passes
> > keyword args.
> > 
> > And the varargs set comprehension is similar to the varargs list
> > comprehension:
> > 
> > [*x for x in it]
> > 
> > If `it` were a list of three items, this would be the same as
> > 
> > [*it[0], *it[1], *it[2]]
> 
> I find all this unreadable and difficult to understand.

I did too, before reading the PEP.

After reading the PEP, it makes perfect sense to me.  Nor is the PEP
complicated...it's just a matter of wrapping your head around the
generalization[*] of what are currently special cases that is going on
here.

--David

[*] The *further* generalization...we've already had, for example,
the generalization that allows:

a, *b = (1, 3, 4)

to work, and that seems very clear to usnow.
___
Python-Dev mailing list
Python-Dev@python.org
https://mail.python.org/mailman/listinfo/python-dev
Unsubscribe: 
https://mail.python.org/mailman/options/python-dev/archive%40mail-archive.com

Re: [Python-Dev] Any grammar experts?

[Antoine Pitrou]

On Sun, 25 Jan 2015 14:59:42 -0800
Guido van Rossum  wrote:
> On Sun, Jan 25, 2015 at 7:32 AM, Georg Brandl  wrote:
> 
> > On 01/25/2015 04:08 PM, Antoine Pitrou wrote:
> > > On Sat, 24 Jan 2015 21:10:51 -0500
> > > Neil Girdhar  wrote:
> > >> To finish PEP 448, I need to update the grammar for syntax such as
> > >>
> > >> {**x for x in it}
> > >
> > > Is this seriously allowed by the PEP? What does it mean exactly?
> >
> > It appears to go a bit far.  Especially since you also would have to allow
> >
> > {*x for x in it}
> >
> > which is a set comprehension, while the other is a dict comprehension :)
> >
> 
> That distinction doesn't bother me -- you might as well claim it's
> confusing that f(*x) passes positional args from x while f(**x) passes
> keyword args.
> 
> And the varargs set comprehension is similar to the varargs list
> comprehension:
> 
> [*x for x in it]
> 
> If `it` were a list of three items, this would be the same as
> 
> [*it[0], *it[1], *it[2]]

I find all this unreadable and difficult to understand.

Regards

Antoine.


___
Python-Dev mailing list
Python-Dev@python.org
https://mail.python.org/mailman/listinfo/python-dev
Unsubscribe: 
https://mail.python.org/mailman/options/python-dev/archive%40mail-archive.com

Re: [Python-Dev] Disassembly of generated comprehensions

[Nick Coghlan]

On 26 Jan 2015 07:58, "Greg Ewing"  wrote:
>
> Petr Viktorin wrote:
>>
>> On Sun, Jan 25, 2015 at 12:55 PM, Neil Girdhar 
wrote:
>>
>>> How do I disassemble a generated comprehension?
>>>
>> Put it in a function, then get it from the function's code's constants.
>
>
> It would be handy if dis had an option to disassemble nested
> functions like this automatically.

The code for that already exists, but it needs someone with the roundtuits
to put together new tests and docs: http://bugs.python.org/issue11822

Cheers,
Nick.

>
> --
> Greg
>
> ___
> Python-Dev mailing list
> Python-Dev@python.org
> https://mail.python.org/mailman/listinfo/python-dev
> Unsubscribe:
https://mail.python.org/mailman/options/python-dev/ncoghlan%40gmail.com
___
Python-Dev mailing list
Python-Dev@python.org
https://mail.python.org/mailman/listinfo/python-dev
Unsubscribe: 
https://mail.python.org/mailman/options/python-dev/archive%40mail-archive.com

Re: [Python-Dev] Any grammar experts?

[Guido van Rossum]

On Sun, Jan 25, 2015 at 7:32 AM, Georg Brandl  wrote:

> On 01/25/2015 04:08 PM, Antoine Pitrou wrote:
> > On Sat, 24 Jan 2015 21:10:51 -0500
> > Neil Girdhar  wrote:
> >> To finish PEP 448, I need to update the grammar for syntax such as
> >>
> >> {**x for x in it}
> >
> > Is this seriously allowed by the PEP? What does it mean exactly?
>
> It appears to go a bit far.  Especially since you also would have to allow
>
> {*x for x in it}
>
> which is a set comprehension, while the other is a dict comprehension :)
>

That distinction doesn't bother me -- you might as well claim it's
confusing that f(*x) passes positional args from x while f(**x) passes
keyword args.

And the varargs set comprehension is similar to the varargs list
comprehension:

[*x for x in it]

If `it` were a list of three items, this would be the same as

[*it[0], *it[1], *it[2]]

so the original is a flattening of `it`: [*it[0], *it[1], ...]. (The type
of `it` is wider than list of lists -- it could be an iterable of
iterables. But the thing is still a flattening.)

The set flattening follows from a direct analogy. And `it` doesn't have to
be a set of sets, it still  just needs to be an iterable of iterables --
it's only the flattened result that's turned into a set.

The dict comprehension follows from there -- the input must be an iterable
of iterables of (key, value) pairs.

I like the example from the PEP, a dict combining globals() and locals():

{**dictionary for dictionary in (globals(), locals())}

This could be written as

{**globals(), **locals()}

but the general case (a variable number of dicts to combine) requires the
comprehension.

The PEP also supports generator expressions that are flattenings, and again
that follows directly from analogy.

Interestingly, the non-dict versions can all be written today using a
double-nested comprehension, e.g. {**x for x in it} can be written as:

{x for x in xs for xs in it}

But it's not so straightforward for dict comprehensions -- you'd have to
switch to calling dict():

dict(x for x in xs for xs in it)

-- 
--Guido van Rossum (python.org/~guido)
___
Python-Dev mailing list
Python-Dev@python.org
https://mail.python.org/mailman/listinfo/python-dev
Unsubscribe: 
https://mail.python.org/mailman/options/python-dev/archive%40mail-archive.com

Re: [Python-Dev] Why are generated files in the repository?

[Nick Coghlan]

On 26 Jan 2015 02:33, "R. David Murray"  wrote:
>
> On Sun, 25 Jan 2015 14:00:57 +1000, Nick Coghlan 
wrote:
> > It's far more developer friendly to aim to have builds from a source
> > check-out "just work" if we can. That's pretty much where we are today
> > (getting external dependencies for the optional parts on *nix can still
be
> > a bit fiddly - it may be worth maintaining instructions for at least apt
> > and yum in the developer guide that cover that)
>
> https://docs.python.org/devguide/setup.html#build-dependencies

Heh, as I was writing that I was thinking, "Did we do that already?". I
should have gone and checked :)

Cheers,
Nick.

> ___
> Python-Dev mailing list
> Python-Dev@python.org
> https://mail.python.org/mailman/listinfo/python-dev
> Unsubscribe:
https://mail.python.org/mailman/options/python-dev/ncoghlan%40gmail.com
___
Python-Dev mailing list
Python-Dev@python.org
https://mail.python.org/mailman/listinfo/python-dev
Unsubscribe: 
https://mail.python.org/mailman/options/python-dev/archive%40mail-archive.com

Re: [Python-Dev] Disassembly of generated comprehensions

[Greg Ewing]

Petr Viktorin wrote:

On Sun, Jan 25, 2015 at 12:55 PM, Neil Girdhar  wrote:


How do I disassemble a generated comprehension?


Put it in a function, then get it from the function's code's constants.


It would be handy if dis had an option to disassemble nested
functions like this automatically.

--
Greg
___
Python-Dev mailing list
Python-Dev@python.org
https://mail.python.org/mailman/listinfo/python-dev
Unsubscribe: 
https://mail.python.org/mailman/options/python-dev/archive%40mail-archive.com

Re: [Python-Dev] Can Python Be Built Without Distutils

[Cyd Haselton]

Thanks...this looks interesting Antonio.  I'm not familiar enough with
Makefile syntax and creation to know if this can help in my case and
(fingers crossed) I believe I've just about solved my original
undefined reference to dlopen problem, but I'll be bookmarking it for
future reference (and in case I'm wrong about being close to solving
my original Android build issues).

On Sun, Jan 25, 2015 at 4:08 AM, Antonio Cavallo
 wrote:
> I tried a Makefile based build of python (+ some module) in the past for
> Android (and macos):
>
>https://bitbucket.org/cavallo71/android
>
> There was no particular problem in dropping autoconfigure+setup.py in the
> process: the only real problem was the pgen must be compiled on the host
> machine (but that could have changed since).
>
> In general python was a plain compile and link stuff with not much magic
> involved and that is (very) good in my opinion: magic detection tends to
> fail, autoconfigure need to "execute" stuff to detect things (reason why is
> quite useless in cross-compile mode) etc.
>
> I would've tried also cmake and qmake builds as well, but simply I didn't
> have time to spend on it.
>
> I hope this helps,
> Antonio
>
>
>
> Zachary Ware wrote:
>>
>> On Saturday, January 24, 2015, Brett Cannon > > wrote:
>>
>> On Fri Jan 23 2015 at 5:45:28 PM Gregory P. Smith > > wrote:
>>
>> On Fri Jan 23 2015 at 11:20:02 AM M.-A. Lemburg > > wrote:
>>
>> On 23.01.2015 19:48, Matthias Klose wrote:
>>  > On 01/23/2015 06:30 PM, Cyd Haselton wrote:
>>  >> Related to my earlier question regarding building Python
>> on Android
>>  >> and an undefined reference to dlopen error...I have the
>> following
>>  >> question:  Is it possible to build and install Python
>> without having
>>  >> to build and install...or use...distutils?
>>  >>
>>  >> Some background:
>>  >> I can build the python interpreter on my device, and I can
>> build a
>>  >> bunch of modules.  The problem appears when make reaches
>> the part
>>  >> where setup.py is used to build and import
>> modules...specifically when
>>  >> setup.py attempts to import distutils.core.
>>  >
>>  > you can do this using Setup.local. This works for me
>> building additional
>>  > extensions as builtins.  It might require some tweaking to
>> build everything.
>>
>> You may want to have a look at the Setup files we're using
>> in eGenix PyRun, which uses them to force static builds of the
>> various built-in extensions.
>>
>> Look for these files:
>>
>> PyRun/Runtime/Setup.PyRun-2.7
>> PyRun/Runtime/Setup.PyRun-3.4
>>
>> in the source archives:
>>
>> http://www.egenix.com/__products/python/PyRun/
>> 
>>
>>  > Otoh, I would like to get rid off the setup.py altogether
>> (/me ducks ...).
>>
>> Why ? It's great for finding stuff on your system and
>> configuring
>> everything without user intervention (well, most of the time
>> :-)).
>>
>>
>> Because our setup.py is a nightmare of arbitrary code run in a
>> linear fashion with ad-hoc checks for things that are
>> unlike how any other project on the planet determines what is
>> available on your system.  It may have seemed "great" when
>> it was created in 2001.  It really shows its age now.
>>
>> It defeats build parallelism and dependency declaration.
>> It also prevents cross compilation.
>>
>> Building an interpreter with a limited standard library on your
>> build host so that you can run said interpreter to have
>> it drive the remainder of your build is way more self hosting that
>> we rightfully need to be for CPython.
>>
>>
>> So are you suggesting to add the build rules to configure and the
>> Makefile -- and Windows build file -- in order to drop
>> setup.py?
>>
>>
>> Windows already doesn't use setup.py. There are a lot more modules
>> built-in on Windows, and others have their own project files;
>> distutils isn't used at all.
>>
>>
>> --
>> Sent from Gmail Mobile
>>
>> ___
>> Python-Dev mailing list
>> Python-Dev@python.org
>> https://mail.python.org/mailman/listinfo/python-dev
>> Unsubscribe:
>> https://mail.python.org/mailman/options/python-dev/a.cavallo%40cavallinux.eu
>
> ___
> Python-Dev mailing list
> Python-Dev@python.org
> https://mail.python.org/mailman/listinfo/python-dev
> Unsubscribe:
> https://mail.python.org/mailman/options/python-dev/chaselton%40gmail.com
___
Python-Dev mailing list
Python-Dev@python.org
https://mail.python.org/mailman/listinfo/python-dev
Unsubscribe

Re: [Python-Dev] Why are generated files in the repository?

[R. David Murray]

On Sun, 25 Jan 2015 14:00:57 +1000, Nick Coghlan  wrote:
> It's far more developer friendly to aim to have builds from a source
> check-out "just work" if we can. That's pretty much where we are today
> (getting external dependencies for the optional parts on *nix can still be
> a bit fiddly - it may be worth maintaining instructions for at least apt
> and yum in the developer guide that cover that)

https://docs.python.org/devguide/setup.html#build-dependencies
___
Python-Dev mailing list
Python-Dev@python.org
https://mail.python.org/mailman/listinfo/python-dev
Unsubscribe: 
https://mail.python.org/mailman/options/python-dev/archive%40mail-archive.com

Re: [Python-Dev] Can Python Be Built Without Distutils

[Cyd Haselton]

Since (judging from the lack of responses) setup.py can't be removed
from the Makefile, I kept troubleshooting.I've managed to get the
build to complete and make install runs instead of throwing an
undefined reference right off the bat, unfortunately I've run into the
following:

ImportError: No module named _struct

This also happens when make test is run.  I;ve checked...the _struct
module is there.

On Sat, Jan 24, 2015 at 11:22 PM, Gregory P. Smith  wrote:
> Why doesn't our Makefile supply that flag with the make parallelism level in
> the sharedmods step?
>
> On Sat Jan 24 2015 at 2:25:45 PM Antoine Pitrou  wrote:
>>
>> On Sat, 24 Jan 2015 21:53:06 +0100
>> "M.-A. Lemburg"  wrote:
>> >
>> > BTW: Parallel execution, cross compilation can be added
>> > to setup.py. I don't think parallel execution is all
>> > that important,
>>
>> $ ./python setup.py build_ext --help
>> [...]
>>   --parallel (-j)  number of parallel build jobs
>>
>>
>> Regards
>>
>> Antoine.
>>
>>
>> ___
>> Python-Dev mailing list
>> Python-Dev@python.org
>> https://mail.python.org/mailman/listinfo/python-dev
>> Unsubscribe:
>> https://mail.python.org/mailman/options/python-dev/greg%40krypto.org
>
>
> ___
> Python-Dev mailing list
> Python-Dev@python.org
> https://mail.python.org/mailman/listinfo/python-dev
> Unsubscribe:
> https://mail.python.org/mailman/options/python-dev/chaselton%40gmail.com
>
___
Python-Dev mailing list
Python-Dev@python.org
https://mail.python.org/mailman/listinfo/python-dev
Unsubscribe: 
https://mail.python.org/mailman/options/python-dev/archive%40mail-archive.com

Re: [Python-Dev] Disassembly of generated comprehensions

[Petr Viktorin]

On Sun, Jan 25, 2015 at 12:55 PM, Neil Girdhar  wrote:
> How do I disassemble a generated comprehension?
>
> For example, I am trying to debug the following:
>
 dis.dis('{**{} for x in [{1:2}]}')
>   1   0 LOAD_CONST   0 ( at
> 0x10160b7c0, file "", line 1>)
>   3 LOAD_CONST   1 ('')
>   6 MAKE_FUNCTION0
>   9 LOAD_CONST   2 (2)
>  12 LOAD_CONST   3 (1)
>  15 BUILD_MAP1
>  18 BUILD_LIST   1
>  21 GET_ITER
>  22 CALL_FUNCTION1 (1 positional, 0 keyword pair)
>  25 RETURN_VALUE
>
> (This requires the new patch in issue 2292.)
>
> The code here looks fine to me, so I need to look into the code object
> .  How do I do that?

Put it in a function, then get it from the function's code's constants.
I don't have the patch applied but it should work like this even for
the new syntax:

>>> import dis
>>> def f(): return {{} for x in [{1:2}]}
...
>>> dis.dis(f)
  1   0 LOAD_CONST   1 ( at
0x7ff2c0647420, file "", line 1>)
  3 LOAD_CONST   2 ('f..')
  6 MAKE_FUNCTION0
  9 BUILD_MAP1
 12 LOAD_CONST   3 (2)
 15 LOAD_CONST   4 (1)
 18 STORE_MAP
 19 BUILD_LIST   1
 22 GET_ITER
 23 CALL_FUNCTION1 (1 positional, 0 keyword pair)
 26 RETURN_VALUE
>>> f.__code__.co_consts[1]  # from "LOAD_CONST 1"
 at 0x7ff2c0647420, file "", line 1>
>>> dis.dis(f.__code__.co_consts[1])
  1   0 BUILD_SET0
  3 LOAD_FAST0 (.0)
>>6 FOR_ITER12 (to 21)
  9 STORE_FAST   1 (x)
 12 BUILD_MAP0
 15 SET_ADD  2
 18 JUMP_ABSOLUTE6
>>   21 RETURN_VALUE
___
Python-Dev mailing list
Python-Dev@python.org
https://mail.python.org/mailman/listinfo/python-dev
Unsubscribe: 
https://mail.python.org/mailman/options/python-dev/archive%40mail-archive.com

Re: [Python-Dev] Any grammar experts?

[Georg Brandl]

On 01/25/2015 04:08 PM, Antoine Pitrou wrote:
> On Sat, 24 Jan 2015 21:10:51 -0500
> Neil Girdhar  wrote:
>> To finish PEP 448, I need to update the grammar for syntax such as
>> 
>> {**x for x in it}
> 
> Is this seriously allowed by the PEP? What does it mean exactly?

It appears to go a bit far.  Especially since you also would have to allow

{*x for x in it}

which is a set comprehension, while the other is a dict comprehension :)

Georg

___
Python-Dev mailing list
Python-Dev@python.org
https://mail.python.org/mailman/listinfo/python-dev
Unsubscribe: 
https://mail.python.org/mailman/options/python-dev/archive%40mail-archive.com

Re: [Python-Dev] Any grammar experts?

[Antoine Pitrou]

On Sat, 24 Jan 2015 21:10:51 -0500
Neil Girdhar  wrote:
> To finish PEP 448, I need to update the grammar for syntax such as
> 
> {**x for x in it}

Is this seriously allowed by the PEP? What does it mean exactly?

Regards

Antoine.


___
Python-Dev mailing list
Python-Dev@python.org
https://mail.python.org/mailman/listinfo/python-dev
Unsubscribe: 
https://mail.python.org/mailman/options/python-dev/archive%40mail-archive.com

Re: [Python-Dev] Can Python Be Built Without Distutils

[Antoine Pitrou]

On Sun, 25 Jan 2015 05:22:48 +
"Gregory P. Smith"  wrote:
> Why doesn't our Makefile supply that flag with the make parallelism level
> in the sharedmods step?

If I run "make -j4" here, it works (on the default branch).

Regards

Antoine.
___
Python-Dev mailing list
Python-Dev@python.org
https://mail.python.org/mailman/listinfo/python-dev
Unsubscribe: 
https://mail.python.org/mailman/options/python-dev/archive%40mail-archive.com

Re: [Python-Dev] Disassembly of generated comprehensions

[Neil Girdhar]

Perfect, thanks!

On Sun, Jan 25, 2015 at 7:08 AM, Petr Viktorin  wrote:

> On Sun, Jan 25, 2015 at 12:55 PM, Neil Girdhar 
> wrote:
> > How do I disassemble a generated comprehension?
> >
> > For example, I am trying to debug the following:
> >
>  dis.dis('{**{} for x in [{1:2}]}')
> >   1   0 LOAD_CONST   0 ( at
> > 0x10160b7c0, file "", line 1>)
> >   3 LOAD_CONST   1 ('')
> >   6 MAKE_FUNCTION0
> >   9 LOAD_CONST   2 (2)
> >  12 LOAD_CONST   3 (1)
> >  15 BUILD_MAP1
> >  18 BUILD_LIST   1
> >  21 GET_ITER
> >  22 CALL_FUNCTION1 (1 positional, 0 keyword pair)
> >  25 RETURN_VALUE
> >
> > (This requires the new patch in issue 2292.)
> >
> > The code here looks fine to me, so I need to look into the code object
> > .  How do I do that?
>
> Put it in a function, then get it from the function's code's constants.
> I don't have the patch applied but it should work like this even for
> the new syntax:
>
> >>> import dis
> >>> def f(): return {{} for x in [{1:2}]}
> ...
> >>> dis.dis(f)
>   1   0 LOAD_CONST   1 ( at
> 0x7ff2c0647420, file "", line 1>)
>   3 LOAD_CONST   2 ('f..')
>   6 MAKE_FUNCTION0
>   9 BUILD_MAP1
>  12 LOAD_CONST   3 (2)
>  15 LOAD_CONST   4 (1)
>  18 STORE_MAP
>  19 BUILD_LIST   1
>  22 GET_ITER
>  23 CALL_FUNCTION1 (1 positional, 0 keyword pair)
>  26 RETURN_VALUE
> >>> f.__code__.co_consts[1]  # from "LOAD_CONST 1"
>  at 0x7ff2c0647420, file "", line 1>
> >>> dis.dis(f.__code__.co_consts[1])
>   1   0 BUILD_SET0
>   3 LOAD_FAST0 (.0)
> >>6 FOR_ITER12 (to 21)
>   9 STORE_FAST   1 (x)
>  12 BUILD_MAP0
>  15 SET_ADD  2
>  18 JUMP_ABSOLUTE6
> >>   21 RETURN_VALUE
>
___
Python-Dev mailing list
Python-Dev@python.org
https://mail.python.org/mailman/listinfo/python-dev
Unsubscribe: 
https://mail.python.org/mailman/options/python-dev/archive%40mail-archive.com

[Python-Dev] Disassembly of generated comprehensions

[Neil Girdhar]

How do I disassemble a generated comprehension?

For example, I am trying to debug the following:

>>> dis.dis('{**{} for x in [{1:2}]}')
  1   0 LOAD_CONST   0 ( at
0x10160b7c0, file "", line 1>)
  3 LOAD_CONST   1 ('')
  6 MAKE_FUNCTION0
  9 LOAD_CONST   2 (2)
 12 LOAD_CONST   3 (1)
 15 BUILD_MAP1
 18 BUILD_LIST   1
 21 GET_ITER
 22 CALL_FUNCTION1 (1 positional, 0 keyword pair)
 25 RETURN_VALUE

(This requires the new patch in issue 2292.)

The code here looks fine to me, so I need to look into the code object
.  How do I do that?

Thanks,

Neil
___
Python-Dev mailing list
Python-Dev@python.org
https://mail.python.org/mailman/listinfo/python-dev
Unsubscribe: 
https://mail.python.org/mailman/options/python-dev/archive%40mail-archive.com

Re: [Python-Dev] Why are generated files in the repository?

[Neil Girdhar]

That makes sense.  Thanks for explaining.

On Sun, Jan 25, 2015 at 4:55 AM, Thomas Wouters  wrote:

>
>
> On Sun, Jan 25, 2015 at 5:05 AM, Neil Girdhar 
> wrote:
>
>> But you can remove Python/graminit.c and "make clean && make" works,
>> right?
>>
>
> If you can write to the directory, yes. Except if you build in a way that
> you can't run pgen on the host system, like in a cross build (this may have
> been fixed with the last few rounds of cross build fixes) or when
> instrumenting Python. Checking these files in trades very minor "committer
> pain" (tossing merge conflicts and regenerating the files) for equally
> minor pain in the much more diverse group of people compiling CPython.
>
>
>>
>> On Sat, Jan 24, 2015 at 11:00 PM, Nick Coghlan 
>> wrote:
>>
>>>
>>> On 25 Jan 2015 01:09, "Benjamin Peterson"  wrote:
>>> >
>>> >
>>> >
>>> > On Sat, Jan 24, 2015, at 03:00, Nick Coghlan wrote:
>>> > > On 20 January 2015 at 10:53, Benjamin Peterson 
>>> > > wrote:
>>> > > >
>>> > > >
>>> > > > On Mon, Jan 19, 2015, at 19:40, Neil Girdhar wrote:
>>> > > >> I was also wondering why files like Python/graminit.c are in the
>>> > > >> respository?  They generate spurious merge conflicts.
>>> > > >
>>> > > > Convenience mostly.
>>> > >
>>> > > It also gets us a round a couple of bootstrapping problems, where
>>> > > generating some of those files requires a working Python interpreter,
>>> > > which you may not have if you just cloned the source tree or unpacked
>>> > > the tarball.
>>> >
>>> > We could distribute the generated files in tarballs as part of the
>>> > release process.
>>>
>>> It's far more developer friendly to aim to have builds from a source
>>> check-out "just work" if we can. That's pretty much where we are today
>>> (getting external dependencies for the optional parts on *nix can still be
>>> a bit fiddly - it may be worth maintaining instructions for at least apt
>>> and yum in the developer guide that cover that)
>>>
>>> Cheers,
>>> Nick.
>>>
>>
>>
>> ___
>> Python-Dev mailing list
>> Python-Dev@python.org
>> https://mail.python.org/mailman/listinfo/python-dev
>> Unsubscribe:
>> https://mail.python.org/mailman/options/python-dev/thomas%40python.org
>>
>>
>
>
> --
> Thomas Wouters 
>
> Hi! I'm an email virus! Think twice before sending your email to help me
> spread!
>
___
Python-Dev mailing list
Python-Dev@python.org
https://mail.python.org/mailman/listinfo/python-dev
Unsubscribe: 
https://mail.python.org/mailman/options/python-dev/archive%40mail-archive.com

Re: [Python-Dev] Can Python Be Built Without Distutils

[Antonio Cavallo]

I tried a Makefile based build of python (+ some module) in the past for 
Android (and macos):

   https://bitbucket.org/cavallo71/android

There was no particular problem in dropping autoconfigure+setup.py in the process: the only real problem was the pgen must be 
compiled on the host machine (but that could have changed since).


In general python was a plain compile and link stuff with not much magic involved and that is (very) good in my opinion: magic 
detection tends to fail, autoconfigure need to "execute" stuff to detect things (reason why is quite useless in cross-compile 
mode) etc.


I would've tried also cmake and qmake builds as well, but simply I didn't have 
time to spend on it.

I hope this helps,
Antonio



Zachary Ware wrote:

On Saturday, January 24, 2015, Brett Cannon mailto:br...@python.org>> wrote:

On Fri Jan 23 2015 at 5:45:28 PM Gregory P. Smith > wrote:

On Fri Jan 23 2015 at 11:20:02 AM M.-A. Lemburg > wrote:

On 23.01.2015 19:48, Matthias Klose wrote:
 > On 01/23/2015 06:30 PM, Cyd Haselton wrote:
 >> Related to my earlier question regarding building Python on 
Android
 >> and an undefined reference to dlopen error...I have the 
following
 >> question:  Is it possible to build and install Python without 
having
 >> to build and install...or use...distutils?
 >>
 >> Some background:
 >> I can build the python interpreter on my device, and I can 
build a
 >> bunch of modules.  The problem appears when make reaches the 
part
 >> where setup.py is used to build and import 
modules...specifically when
 >> setup.py attempts to import distutils.core.
 >
 > you can do this using Setup.local. This works for me building 
additional
 > extensions as builtins.  It might require some tweaking to build 
everything.

You may want to have a look at the Setup files we're using
in eGenix PyRun, which uses them to force static builds of the
various built-in extensions.

Look for these files:

PyRun/Runtime/Setup.PyRun-2.7
PyRun/Runtime/Setup.PyRun-3.4

in the source archives:

http://www.egenix.com/__products/python/PyRun/ 


 > Otoh, I would like to get rid off the setup.py altogether (/me 
ducks ...).

Why ? It's great for finding stuff on your system and configuring
everything without user intervention (well, most of the time :-)).


Because our setup.py is a nightmare of arbitrary code run in a linear 
fashion with ad-hoc checks for things that are
unlike how any other project on the planet determines what is available on your 
system.  It may have seemed "great" when
it was created in 2001.  It really shows its age now.

It defeats build parallelism and dependency declaration.
It also prevents cross compilation.

Building an interpreter with a limited standard library on your build 
host so that you can run said interpreter to have
it drive the remainder of your build is way more self hosting that we 
rightfully need to be for CPython.


So are you suggesting to add the build rules to configure and the Makefile 
-- and Windows build file -- in order to drop
setup.py?


Windows already doesn't use setup.py. There are a lot more modules built-in on 
Windows, and others have their own project files;
distutils isn't used at all.


--
Sent from Gmail Mobile

___
Python-Dev mailing list
Python-Dev@python.org
https://mail.python.org/mailman/listinfo/python-dev
Unsubscribe: 
https://mail.python.org/mailman/options/python-dev/a.cavallo%40cavallinux.eu

___
Python-Dev mailing list
Python-Dev@python.org
https://mail.python.org/mailman/listinfo/python-dev
Unsubscribe: 
https://mail.python.org/mailman/options/python-dev/archive%40mail-archive.com

Re: [Python-Dev] Why are generated files in the repository?

[Thomas Wouters]

On Sun, Jan 25, 2015 at 5:05 AM, Neil Girdhar  wrote:

> But you can remove Python/graminit.c and "make clean && make" works, right?
>

If you can write to the directory, yes. Except if you build in a way that
you can't run pgen on the host system, like in a cross build (this may have
been fixed with the last few rounds of cross build fixes) or when
instrumenting Python. Checking these files in trades very minor "committer
pain" (tossing merge conflicts and regenerating the files) for equally
minor pain in the much more diverse group of people compiling CPython.


>
> On Sat, Jan 24, 2015 at 11:00 PM, Nick Coghlan  wrote:
>
>>
>> On 25 Jan 2015 01:09, "Benjamin Peterson"  wrote:
>> >
>> >
>> >
>> > On Sat, Jan 24, 2015, at 03:00, Nick Coghlan wrote:
>> > > On 20 January 2015 at 10:53, Benjamin Peterson 
>> > > wrote:
>> > > >
>> > > >
>> > > > On Mon, Jan 19, 2015, at 19:40, Neil Girdhar wrote:
>> > > >> I was also wondering why files like Python/graminit.c are in the
>> > > >> respository?  They generate spurious merge conflicts.
>> > > >
>> > > > Convenience mostly.
>> > >
>> > > It also gets us a round a couple of bootstrapping problems, where
>> > > generating some of those files requires a working Python interpreter,
>> > > which you may not have if you just cloned the source tree or unpacked
>> > > the tarball.
>> >
>> > We could distribute the generated files in tarballs as part of the
>> > release process.
>>
>> It's far more developer friendly to aim to have builds from a source
>> check-out "just work" if we can. That's pretty much where we are today
>> (getting external dependencies for the optional parts on *nix can still be
>> a bit fiddly - it may be worth maintaining instructions for at least apt
>> and yum in the developer guide that cover that)
>>
>> Cheers,
>> Nick.
>>
>
>
> ___
> Python-Dev mailing list
> Python-Dev@python.org
> https://mail.python.org/mailman/listinfo/python-dev
> Unsubscribe:
> https://mail.python.org/mailman/options/python-dev/thomas%40python.org
>
>


-- 
Thomas Wouters 

Hi! I'm an email virus! Think twice before sending your email to help me
spread!
___
Python-Dev mailing list
Python-Dev@python.org
https://mail.python.org/mailman/listinfo/python-dev
Unsubscribe: 
https://mail.python.org/mailman/options/python-dev/archive%40mail-archive.com