Re: [Python-Dev] ubuntu buildbot

[David Bolen]

On Mon, Nov 24, 2014 at 11:07 AM, Benjamin Peterson  wrote:
>
> On Mon, Nov 24, 2014, at 00:33, David Bolen wrote:
>> Yeah, it definitely needs it.  Historically it was intentional as my own
>> servers were all on 8.04, but the last of those moved 12.04 last year.
>>
>> I think there's already a 12.04 buildbot, so perhaps 14.04 would be
>> better?  I do prefer sticking with an LTS.
>
> 14.04 would be good.
>
>> It'll need to move to 64-bit given the hosting environment, at least for
>> the kernel.  I could do 32-bit userspace via multiarch if keeping a 32-bit
>> buildbot in the mix is attractive.
>
> It'd be nice to keep a 32-bit bot around.

Took a bit longer than anticipated, but the slave upgrade is complete.

The bolen-ubuntu slave is now a 32-bit Ubuntu 14.04.2 LTS system.
I've re-run the most recent 2.7, 3.4 and 3.x builds which all pass
(though with a few new compiler warnings in some cases).

-- David
___
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] Request for Pronouncement: PEP 441 - Improving Python ZIP Application Support

[Paul Moore]

On 25 February 2015 at 20:12, Jim J. Jewett  wrote:
> On Wed, Feb 25, 2015 at 2:33 PM, Paul Moore  wrote:
>> On 25 February 2015 at 17:06, Paul Moore  wrote:
>
>> I've included the resulting API
>> documentation below. It looks pretty good to me.
>
> Me too.  I have a few nits anyhow.
>
>> .. function:: create_archive(directory, target=None, interpreter=None,
>> main=None)
>
>>Create an application archive from *source*.  The source can be any
>>of the following:
>
> (1)  *source* makes me think of source code, as opposed to binary.
> This is only a small objection, in part because I can't think of
> anything better.
>
> (2)  If you do keep *source*, I think that the the "directory"
> parameter should be renamed to "source".

Yep, that's a typo. Think of it as source -> target as opposed to
source code and it's fine :-)

> (3)
>>* The name of an existing application archive file, in which case the
>>  file is copied to the target.
>
> ==>
>
>>* The name of an existing application archive file, in which case the
>>  file is copied (possibly with changes) to the target.
>
> My concern is that someone who does want just another copy will use
> this, see "copied", not read the other options, and be surprised when
> the shebang is dropped.

Hmm, how about "... the content of the archive is copied to the target
with a replacement shebang line"?

>
>>* A file object open for reading in bytes mode.  The content of the
>>  file should be an application archive, and the file object is
>>  assumed to be positioned at the start of the archive.
>
> I like this way of ducking the "does it need to be seekable" question.

:-)

>>The *target* argument determines where the resulting archive will be
>>written:
>>
>>* If it is the name of a file, the archive will be written to that
>>  file.
>
> (4)  Note that the filename is not required to end with pyz, although
> that is good practice.  Or maybe just be explicit that the function
> itself does not add a .pyz, and assumes that the caller will do so
> when appropriate.

Hmm, I thought I'd added an explanation. Maybe I did that somewhere
else and missed it here. I'll clarify.

>>The *interpreter* argument specifies the name of the Python
>>interpreter with which the archive will be executed.  ...
>>   ...  Omitting the *interpreter* results in no shebang line being
>>written.
>
> (5)  even if there was an explicit shebang line in the source archive.

I'll clarify the wording.

>>  If an interpreter is specified, and the target is a
>>filename, the executable bit of the target file will be set.
>
> (6) (target is a filename, or None)  Or does that clarification just
> confuse the issue, and only benefit people so careful they'll verify
> it themselves anyway?

Probably :-) How about "if the target is a real file" or "unless the
target is a file-like object"? But in all honesty I think it's fine as
is.

> (7)  That is a good idea, but not quite as clear cut as it sounds.  On
> unix, there are generally 3 different executable bits specifying *who*
> can run it.  Setting the executable bit only for the owner is probably
> a conservative but sensible default.

I know, but excuse the naivete of a Windows user. I'm inclined to
leave it as it is and direct people to read the source if they care
that much (I actually used I_EXEC, which is what I've seen other code
use). The alternative is to not set the executable bit at all and make
the user do it as a separate step. My instinct is that doing that
would be less user friendly, but my instincts on what's good Unix
behaviour aren't strong...

Thanks for the comments.
Paul
___
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] Request for Pronouncement: PEP 441 - Improving Python ZIP Application Support

[Jim J. Jewett]

On Wed, Feb 25, 2015 at 2:33 PM, Paul Moore  wrote:
> On 25 February 2015 at 17:06, Paul Moore  wrote:

> I've included the resulting API
> documentation below. It looks pretty good to me.

Me too.  I have a few nits anyhow.

> .. function:: create_archive(directory, target=None, interpreter=None,
> main=None)

>Create an application archive from *source*.  The source can be any
>of the following:

(1)  *source* makes me think of source code, as opposed to binary.
This is only a small objection, in part because I can't think of
anything better.

(2)  If you do keep *source*, I think that the the "directory"
parameter should be renamed to "source".

(3)
>* The name of an existing application archive file, in which case the
>  file is copied to the target.

==>

>* The name of an existing application archive file, in which case the
>  file is copied (possibly with changes) to the target.

My concern is that someone who does want just another copy will use
this, see "copied", not read the other options, and be surprised when
the shebang is dropped.


>* A file object open for reading in bytes mode.  The content of the
>  file should be an application archive, and the file object is
>  assumed to be positioned at the start of the archive.

I like this way of ducking the "does it need to be seekable" question.

>The *target* argument determines where the resulting archive will be
>written:
>
>* If it is the name of a file, the archive will be written to that
>  file.

(4)  Note that the filename is not required to end with pyz, although
that is good practice.  Or maybe just be explicit that the function
itself does not add a .pyz, and assumes that the caller will do so
when appropriate.

>The *interpreter* argument specifies the name of the Python
>interpreter with which the archive will be executed.  ...
>   ...  Omitting the *interpreter* results in no shebang line being
>written.

(5)  even if there was an explicit shebang line in the source archive.

>  If an interpreter is specified, and the target is a
>filename, the executable bit of the target file will be set.

(6) (target is a filename, or None)  Or does that clarification just
confuse the issue, and only benefit people so careful they'll verify
it themselves anyway?

(7)  That is a good idea, but not quite as clear cut as it sounds.  On
unix, there are generally 3 different executable bits specifying *who*
can run it.  Setting the executable bit only for the owner is probably
a conservative but sensible default.

-jJ
___
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] Request for Pronouncement: PEP 441 - Improving Python ZIP Application Support

[Barry Warsaw]

On Feb 25, 2015, at 07:33 PM, Paul Moore wrote:

>The module defines two convenience functions:
>
>
>.. function:: create_archive(directory, target=None, interpreter=None,
>main=None)
>
>   Create an application archive from *source*.  The source can be any
>   of the following:

I think you meant s/directory/source/ in the signature.

Other than that, +1.

Cheers,
-Barry
___
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] PEP 448 review

[Guido van Rossum]

I'm back, I've re-read the PEP, and I've re-read the long thread with "(no
subject)".

I think Georg Brandl nailed it:

"""








*I like the "sequence and dict flattening" part of the PEP, mostly because
itis consistent and should be easy to understand, but the comprehension
syntaxenhancements seem to be bad for readability and "comprehending" what
the codedoes.The call syntax part is a mixed bag on the one hand it is nice
to be consistent with the extended possibilities in literals (flattening),
but on the other hand there would be small but annoying inconsistencies
anyways (e.g. the duplicate kwarg case above).*
"""

Greg Ewing followed up explaining that the inconsistency between dict
flattening and call syntax is inherent in the pre-existing different rules
for dicts vs. keyword args: {'a':1, 'a':2} results in {'a':2}, while f(a=1,
a=2) is an error. (This form is a SyntaxError; the dynamic case f(a=1,
**{'a': 1}) is a TypeError.)

For me, allowing f(*a, *b) and f(**d, **e) and all the other combinations
for function calls proposed by the PEP is an easy +1 -- it's a
straightforward extension of the existing pattern, and anybody who knows
what f(x, *a) does will understand f(x, *a, y, *b). Guessing what f(**d,
**e) means shouldn't be hard either. Understanding the edge case for
duplicate keys with f(**d, **e) is a little harder, but the error messages
are pretty clear, and it is not a new edge case.

The sequence and dict flattening syntax proposals are also clean and
logical -- we already have *-unpacking on the receiving side, so allowing
*x in tuple expressions reads pretty naturally (and the similarity with *a
in argument lists certainly helps). From here, having [a, *x, b, *y] is
also natural, and then the extension to other displays is natural: {a, *x,
b, *y} and {a:1, **d, b:2, **e}. This, too, gets a +1 from me.

So that leaves comprehensions. IIRC, during the development of the patch we
realized that f(*x for x in xs) is sufficiently ambiguous that we decided
to disallow it -- note that f(x for x in xs) is already somewhat of a
special case because an argument can only be a "bare" generator expression
if it is the only argument. The same reasoning doesn't apply (in that form)
to list, set and dict comprehensions -- while f(x for x in xs) is identical
in meaning to f((x for x in xs)), [x for x in xs] is NOT the same as [(x
for x in xs)] (that's a list of one element, and the element is a generator
expression).

The basic premise of this part of the proposal is that if you have a few
iterables, the new proposal (without comprehensions) lets you create a list
or generator expression that iterates over all of them, essentially
flattening them:

>>> xs = [1, 2, 3]
>>> ys = ['abc', 'def']
>>> zs = [99]
>>> [*xs, *ys, *zs]
[1, 2, 3, 'abc', 'def', 99]
>>>

But now suppose you have a list of iterables:

>>> xss = [[1, 2, 3], ['abc', 'def'], [99]]
>>> [*xss[0], *xss[1], *xss[2]]
[1, 2, 3, 'abc', 'def', 99]
>>>

Wouldn't it be nice if you could write the latter using a comprehension?

>>> xss = [[1, 2, 3], ['abc', 'def'], [99]]
>>> [*xs for xs in xss]
[1, 2, 3, 'abc', 'def', 99]
>>>

This is somewhat seductive, and the following is even nicer: the *xs
position may be an expression, e.g.:

>>> xss = [[1, 2, 3], ['abc', 'def'], [99]]
>>> [*xs[:2] for xs in xss]
[1, 2, 'abc', 'def', 99]
>>>

On the other hand, I had to explore the possibilities here by experimenting
in the interpreter, and I discovered some odd edge cases (e.g. you can
parenthesize the starred expression, but that seems a syntactic accident).

All in all I am personally +0 on the comprehension part of the PEP, and I
like that it provides a way to "flatten" a sequence of sequences, but I
think very few people in the thread have supported this part. Therefore I
would like to ask Neil to update the PEP and the patch to take out the
comprehension part, so that the two "easy wins" can make it into Python 3.5
(basically, I am accepting two-thirds of the PEP :-). There is some time
yet until alpha 2.

I would also like code reviewers (Benjamin?) to start reviewing the patch
, taking into account that the
comprehension part needs to be removed.

-- 
--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] Request for Pronouncement: PEP 441 - Improving Python ZIP Application Support

[Brett Cannon]

On Wed, Feb 25, 2015 at 2:33 PM Paul Moore  wrote:

> On 25 February 2015 at 17:06, Paul Moore  wrote:
> >> Is the difference between create and copy important?  e.g., is there
> >> anything wrong with
> >>
> >> create_archive(old_archive, output=new_archive) working as well as
> >> create_archive(directory, archive)?
> >
> > Probably not, now. The semantics have converged enough that this might
> > be reasonable. It's how the command line interface works, after all.
> > It would mean that the behaviour would be different depending on the
> > value of the source argument (supplying the main argument and omitting
> > the target are only valid for create), but again that's how the
> > command line works.
> >
> > I'll have a go at implementing this change this evening and see how it
> > plays out.
>
> That worked out pretty well, IMO. The resulting API is a lot cleaner
> (internally, there's not much change, I still have a copy_archive
> function but it's now private). I've included the resulting API
> documentation below. It looks pretty good to me.
>
> Does anyone have any further suggestions or comments, or does this
> look ready to go back to Guido for a second review?
>

+1 from me.

-Brett


>
> Paul
>
> Python API
> --
>
> The module defines two convenience functions:
>
>
> .. function:: create_archive(directory, target=None, interpreter=None,
> main=None)
>
>Create an application archive from *source*.  The source can be any
>of the following:
>
>* The name of a directory, in which case a new application archive
>  will be created from the content of that directory.
>* The name of an existing application archive file, in which case the
>  file is copied to the target.  The file name should include the
>  ``.pyz`` extension, if required.
>* A file object open for reading in bytes mode.  The content of the
>  file should be an application archive, and the file object is
>  assumed to be positioned at the start of the archive.
>
>The *target* argument determines where the resulting archive will be
>written:
>
>* If it is the name of a file, the archive will be written to that
>  file.
>* If it is an open file object, the archive will be written to that
>  file object, which must be open for writing in bytes mode.
>* If the target is omitted (or None), the source must be a directory
>  and the target will be a file with the same name as the source, with
>  a ``.pyz`` extension added.
>
>The *interpreter* argument specifies the name of the Python
>interpreter with which the archive will be executed.  It is written as
>a "shebang" line at the start of the archive.  On POSIX, this will be
>interpreted by the OS, and on Windows it will be handled by the Python
>launcher.  Omitting the *interpreter* results in no shebang line being
>written.  If an interpreter is specified, and the target is a
>filename, the executable bit of the target file will be set.
>
>The *main* argument specifies the name of a callable which will be
>used as the main program for the archive.  It can only be specified if
>the source is a directory, and the source does not already contain a
>``__main__.py`` file.  The *main* argument should take the form
>"pkg.module:callable" and the archive will be run by importing
>"pkg.module" and executing the given callable with no arguments.  It
>is an error to omit *main* if the source is a directory and does not
>contain a ``__main__.py`` file, as otherwise the resulting archive
>would not be executable.
>
>If a file object is specified for *source* or *target*, it is the
>caller's responsibility to close it after calling create_archive.
>
>When copying an existing archive, file objects supplied only need
>``read`` and ``readline``, or ``write`` methods.  When creating an
>archive from a directory, if the target is a file object it will be
>passed to the ``zipfile.ZipFile`` class, and must supply the methods
>needed by that class.
>
> .. function:: get_interpreter(archive)
>
>Return the interpreter specified in the ``#!`` line at the start of the
>archive.  If there is no ``#!`` line, return :const:`None`.
>The *archive* argument can be a filename or a file-like object open
>for reading in bytes mode.  It is assumed to be at the start of the
> archive.
> ___
> 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/
> brett%40python.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/archive%40mail-archive.com

Re: [Python-Dev] Request for Pronouncement: PEP 441 - Improving Python ZIP Application Support

[Paul Moore]

On 25 February 2015 at 17:06, Paul Moore  wrote:
>> Is the difference between create and copy important?  e.g., is there
>> anything wrong with
>>
>> create_archive(old_archive, output=new_archive) working as well as
>> create_archive(directory, archive)?
>
> Probably not, now. The semantics have converged enough that this might
> be reasonable. It's how the command line interface works, after all.
> It would mean that the behaviour would be different depending on the
> value of the source argument (supplying the main argument and omitting
> the target are only valid for create), but again that's how the
> command line works.
>
> I'll have a go at implementing this change this evening and see how it
> plays out.

That worked out pretty well, IMO. The resulting API is a lot cleaner
(internally, there's not much change, I still have a copy_archive
function but it's now private). I've included the resulting API
documentation below. It looks pretty good to me.

Does anyone have any further suggestions or comments, or does this
look ready to go back to Guido for a second review?

Paul

Python API
--

The module defines two convenience functions:


.. function:: create_archive(directory, target=None, interpreter=None,
main=None)

   Create an application archive from *source*.  The source can be any
   of the following:

   * The name of a directory, in which case a new application archive
 will be created from the content of that directory.
   * The name of an existing application archive file, in which case the
 file is copied to the target.  The file name should include the
 ``.pyz`` extension, if required.
   * A file object open for reading in bytes mode.  The content of the
 file should be an application archive, and the file object is
 assumed to be positioned at the start of the archive.

   The *target* argument determines where the resulting archive will be
   written:

   * If it is the name of a file, the archive will be written to that
 file.
   * If it is an open file object, the archive will be written to that
 file object, which must be open for writing in bytes mode.
   * If the target is omitted (or None), the source must be a directory
 and the target will be a file with the same name as the source, with
 a ``.pyz`` extension added.

   The *interpreter* argument specifies the name of the Python
   interpreter with which the archive will be executed.  It is written as
   a "shebang" line at the start of the archive.  On POSIX, this will be
   interpreted by the OS, and on Windows it will be handled by the Python
   launcher.  Omitting the *interpreter* results in no shebang line being
   written.  If an interpreter is specified, and the target is a
   filename, the executable bit of the target file will be set.

   The *main* argument specifies the name of a callable which will be
   used as the main program for the archive.  It can only be specified if
   the source is a directory, and the source does not already contain a
   ``__main__.py`` file.  The *main* argument should take the form
   "pkg.module:callable" and the archive will be run by importing
   "pkg.module" and executing the given callable with no arguments.  It
   is an error to omit *main* if the source is a directory and does not
   contain a ``__main__.py`` file, as otherwise the resulting archive
   would not be executable.

   If a file object is specified for *source* or *target*, it is the
   caller's responsibility to close it after calling create_archive.

   When copying an existing archive, file objects supplied only need
   ``read`` and ``readline``, or ``write`` methods.  When creating an
   archive from a directory, if the target is a file object it will be
   passed to the ``zipfile.ZipFile`` class, and must supply the methods
   needed by that class.

.. function:: get_interpreter(archive)

   Return the interpreter specified in the ``#!`` line at the start of the
   archive.  If there is no ``#!`` line, return :const:`None`.
   The *archive* argument can be a filename or a file-like object open
   for reading in bytes mode.  It is assumed to be at the start of the archive.
___
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] Working on issue 23496: should I use a macro test or an edit to configure.ac?

[Ryan Gonzalez]

So...

There was a recent discussion here on porting Python to Android. Well, for
those of you who saw too many unread messages and marked the whole thread
as read like I usually do, I helped Cyd figure out some patches that make
it work. Cyd then opened Issue 23496 .
Now, I'm going to try to redo the patches against HEAD (or tip in Mercurial
language).

Which leads me to the question. See, of course, the patches should only be
enabled if Python is being built targeting Android, but I'm not sure how
that should be detected.

I know that the Android target triple is arm-linux-androideabi. Should I
test for the __ANDROID__ macro in the source file, or should I modify
configure.ac to detect Android and define its own macro? Also, if a
configure.ac edit is preferred, where should it be? It's slightly painful
to scan through all 4000 lines of Python's configure script. ;)

-- 
Ryan
If anybody ever asks me why I prefer C++ to C, my answer will be simple:
"It's becauseslejfp23(@#Q*(E*EIdc-SEGFAULT. Wait, I don't think that was
nul-terminated."
Personal reality distortion fields are immune to contradictory evidence. -
srean
Check out my website: http://kirbyfan64.github.io/
___
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] Request for Pronouncement: PEP 441 - Improving Python ZIP Application Support

[Paul Moore]

On 25 February 2015 at 16:02, Jim J. Jewett  wrote:
> On 24 February 2015 at 18:58, Guido van Rossum  wrote:
>> The naming of the functions feels inconsistent -- maybe pack(directory,
>> target) -> create_archive(directory, archive), and set_interpreter() ->
>> copy_archive(archive, new_archive)?
>
>
> Paul Moore wrote:
>> One possible source of confusion with copy_archive (and its command
>> line equivalent "python -m zipapp old.pyz -o new.pyz") is that it
>> isn't technically a copy, as it changes the shebang line (if you omit
>> the interpreter argument it removes the existing shebang).
>
> Is the difference between create and copy important?  e.g., is there
> anything wrong with
>
> create_archive(old_archive, output=new_archive) working as well as
> create_archive(directory, archive)?

Probably not, now. The semantics have converged enough that this might
be reasonable. It's how the command line interface works, after all.
It would mean that the behaviour would be different depending on the
value of the source argument (supplying the main argument and omitting
the target are only valid for create), but again that's how the
command line works.

I'll have a go at implementing this change this evening and see how it
plays out.

Paul
___
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] Request for Pronouncement: PEP 441 - Improving Python ZIP Application Support

[Jim J. Jewett]

On 24 February 2015 at 18:58, Guido van Rossum  wrote:
> The naming of the functions feels inconsistent -- maybe pack(directory,
> target) -> create_archive(directory, archive), and set_interpreter() ->
> copy_archive(archive, new_archive)?


Paul Moore wrote:
> One possible source of confusion with copy_archive (and its command
> line equivalent "python -m zipapp old.pyz -o new.pyz") is that it
> isn't technically a copy, as it changes the shebang line (if you omit
> the interpreter argument it removes the existing shebang).

Is the difference between create and copy important?  e.g., is there
anything wrong with

create_archive(old_archive, output=new_archive) working as well as
create_archive(directory, archive)?

-jJ

--

If there are still threading problems with my replies, please
email me with details, so that I can try to resolve them.  -jJ
___
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] how to inspect if something includes a bound first param

[Larry Hastings]

On 02/24/2015 05:56 PM, Gregory P. Smith wrote:
inspect.getargspec(method) and inspect.signature(method) both include 
the 'self' parameter but how are we to figure out from method itself 
that it is actually bound and that its first parameter is expected to 
be a bound instance?


Given the mechanisms involved, surely this question is a bit 
nonsensical?  The function doesn't "expect" anything, it's just a 
function.  (I remind you, Python 3 dropped the whole concept of an 
"unbound method".)  If it happens to live inside a class, and it's 
accessed through an instance of the class, then the first parameter gets 
bound.


Consider:

>>> class A:
   ...   def x(self, a): print(a)
   ...
>>> a = A()

inspect.signature(A.x).parameters has two parameters, "self" and "a".
inspect.signature(a.x).parameters has only one parameter, "a".

I claiim this is what you want.  It's analagous to a functools.partial 
object.  It would be awfully confusing if the signature of a 
functools.partial object include the parameters handled by the partial 
object.


IMO inspect.getargspec and inspect.getfullargspec get this wrong; for 
a.x they include the "self" parameter.  If you were constructing a call 
to this function dynamically you'd include one too many parameters.



//arry/
___
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] ?s re documentation of Python features

[Nick Coghlan]

On 25 February 2015 at 11:43, Ryan Gonzalez  wrote:
> Ask on python-list. Also check out the FAQ and the Help page. Not sure what
> your problem is; Python is EXTREMELY well documented.

The core Python docs aren't bad, but getting the full scientific
Python stack up and running is still challenging for most folks.

Garry, while Ryan is correct that python-list or python-tutor would be
a better venue for this question (python-dev is for discussing the
development *of* Python, rather than *with* Python), you may also be
interested to know that getting the scientific Python stack up and
running has its own dedicated section in the Python Packaging User's
Guide: https://packaging.python.org/en/latest/science.html

In particular, it is likely to be worth your time t to look at
adopting one of the downstream Scientific Python distributions, rather
than attempting to use upstream Python directly:
http://www.scipy.org/install.html

Regards,
Nick.


>
> On Tue, Feb 24, 2015 at 7:15 PM, GARRY M CRANE  wrote:
>>
>> I am trying to learn Python for use in computational biology.  I am using
>> the interesting book: "Computing for Biologists; Python Programming and
>> Principles" (by Ran Libeskind-Hadas and Eliot Bush).  It has an interesting
>> and useful set of programming exercises at www.cs.hmc.edu/CFB.  I am
>> actually enjoying solving (doing) the example problems.  However, I find
>> some of the instructions non-functional for me.  For example the import
>> function does not work,  nor f=open("filename.txt").  I have saved files per
>> instructions in the programming exercise inside the Python34 folder (I am
>> using Python 3.4 in Windows 7).  But use of the f=open() command produces an
>> error message that the requested file does not exist. I assume I have chosen
>> a wrong location for the saved file within that Python34 folder, but trial
>> and error has not led to a successful use of these functions.  import simply
>> leaves a blank line .. no suggestion about the problem.
>>
>>
>> Asking questions in Google and Ask about  where to save Python-related
>> files that can be used subsequently have not led to answers - just details
>> about structuring or formatting things to be written/saved/use of the \n at
>> end of each line, etc.  Important details, but of no help.   I am finding
>> Python to be very handy at many biologic things such as working with DNA
>> strings, etc. but I find the documentation and indexing for finding how to
>> use many Python features exasperating.  I am writing to you based on a READ
>> ME file in my Python folder - generated when I installed Python.
>>
>> FYI, I asked a few questions of one of the authors of the interesting book
>> - who politely replied he was too busy to answer right now - the book and
>> problems were meant for a class ... though neither the book nor problems say
>> so.  The professor hopes to get around to issues of use by non-students
>> sometime - but not now.
>>
>> Another feature I have come across so far that does not work is
>> importation of matplotlib.  I copy computed results (that otherwise would go
>> to your plotting routine)  then go to Excel and with manipulation produce a
>> usable chart there - but at a cost of time and energy.
>>
>> Your Python tool has many intriguing features - but some of the most basic
>> functions do not work for me (even though many features do, e.g., import
>> random does work).  The failure of these features - so far as I can tell -
>> is  because of lack of description (for the general non-expert public) about
>> where/how to install various features.  Perhaps I need to reinstall from the
>> ground up???  If so, just what should I do?  If there is a less drastic
>> solution, can you tell me about it?
>>
>> Thank you for any help ... and if you could provide me a lead regarding
>> WHERE to ask subsequent questions I would be most grateful.  Sometimes,
>> Google or Ask or a U Tube tutorial does a good job - but if one does not
>> know the 'proper' name or term for something, it often is frustrating or
>> impossible to get an answer.  I have not heard about any comprehensive
>> handbook for Python34 aimed at one who wants to use Python for creating
>> programs (functions) that work - and is not an expert at back-room structure
>> of files and folders have I simply missed it?  So far, I have not found
>> a local Python expert to ask for help.  I am sure some are in the greater
>> Seattle area where I live- but I don't know how to find even one at this
>> time.
>>
>> Garry Crane
>> gandkcr...@msn.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/rymg19%40gmail.com
>>
>
>
>
> --
> Ryan
> If anybody ever asks me why I prefer C++ to C, my answer will be simple:
> "It's becauseslejfp23(@#Q*(E*EIdc-SEGFAULT. Wait, I don't think that was
> nul-

Re: [Python-Dev] Request for Pronouncement: PEP 441 - Improving Python ZIP Application Support

[Paul Moore]

On 24 February 2015 at 18:58, Guido van Rossum  wrote:
> The naming of the functions feels inconsistent -- maybe pack(directory,
> target) -> create_archive(directory, archive), and set_interpreter() ->
> copy_archive(archive, new_archive)?

One possible source of confusion with copy_archive (and its command
line equivalent "python -m zipapp old.pyz -o new.pyz") is that it
isn't technically a copy, as it changes the shebang line (if you omit
the interpreter argument it removes the existing shebang). We could
change it to copy by default, but (a) that's redundant as a file copy
works better, and (b) we'd need to add a method of specifying "remove
the shebang" to replace omitting the interpreter arg.

Is this a big enough issue to be worth changing the name of the
function and the command line behaviour? I'm inclined to leave it, but
mainly on the basis that I feel like I'm getting to the point of
over-thinking things...

Paul
___
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] Request for Pronouncement: PEP 441 - Improving Python ZIP Application Support

[Serhiy Storchaka]

On 24.02.15 21:01, Guido van Rossum wrote:

On Tue, Feb 24, 2015 at 10:50 AM, Paul Moore mailto:p.f.mo...@gmail.com>> wrote:

On 24 February 2015 at 18:24, Guido van Rossum mailto:gu...@python.org>> wrote:
> I'd specify that when the output argument is a file open for writing, it 
is
> the caller's responsibility to close the file.  Also, can the file be a
> pipe?  (I.e. are we using seek()/tell() or not?)  And what about the input
> archive?  Can that be a file open for reading?

I'll clarify all of these points. They are mostly "it can be whatever
the zipfile module accepts", though, which isn't explicitly stated
itself :-(


See issue23252.

https://bugs.python.org/issue23252


___
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