Re: [Python-Dev] how to inspect if something includes a bound first param
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
On 25 February 2015 at 11:43, Ryan Gonzalez rym...@gmail.com 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 gandkcr...@msn.com 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-terminated. Personal reality distortion fields are immune to contradictory evidence. - srean Check out my
Re: [Python-Dev] Request for Pronouncement: PEP 441 - Improving Python ZIP Application Support
On 24 February 2015 at 18:58, Guido van Rossum guido at python.org 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] Request for Pronouncement: PEP 441 - Improving Python ZIP Application Support
On 25 February 2015 at 16:02, Jim J. Jewett jimjjew...@gmail.com wrote: On 24 February 2015 at 18:58, Guido van Rossum guido at python.org 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
[Python-Dev] PEP 448 review
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
http://bugs.python.org/issue2292, 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
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
Re: [Python-Dev] Request for Pronouncement: PEP 441 - Improving Python ZIP Application Support
On Wed, Feb 25, 2015 at 2:33 PM, Paul Moore p.f.mo...@gmail.com wrote: On 25 February 2015 at 17:06, Paul Moore p.f.mo...@gmail.com 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
On Wed, Feb 25, 2015 at 2:33 PM Paul Moore p.f.mo...@gmail.com wrote: On 25 February 2015 at 17:06, Paul Moore p.f.mo...@gmail.com 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
[Python-Dev] Working on issue 23496: should I use a macro test or an edit to configure.ac?
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 http://bugs.python.org/issue23496. 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
On 25 February 2015 at 17:06, Paul Moore p.f.mo...@gmail.com 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
Re: [Python-Dev] Request for Pronouncement: PEP 441 - Improving Python ZIP Application Support
On 25 February 2015 at 20:12, Jim J. Jewett jimjjew...@gmail.com wrote: On Wed, Feb 25, 2015 at 2:33 PM, Paul Moore p.f.mo...@gmail.com wrote: On 25 February 2015 at 17:06, Paul Moore p.f.mo...@gmail.com 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] ubuntu buildbot
On Mon, Nov 24, 2014 at 11:07 AM, Benjamin Peterson benja...@python.org 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
On 24 February 2015 at 18:58, Guido van Rossum gu...@python.org 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
On 24.02.15 21:01, Guido van Rossum wrote: On Tue, Feb 24, 2015 at 10:50 AM, Paul Moore p.f.mo...@gmail.com mailto:p.f.mo...@gmail.com wrote: On 24 February 2015 at 18:24, Guido van Rossum gu...@python.org 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
