Re: [Python-Dev] How to document functions with optional positional parameters?
Le samedi 21 mars 2015, Serhiy Storchaka a écrit : > > For example binascii.crc32(). It has two positional parameters, one is mandatory, and one is optional with default value 0. With Argument Clinic its signature is crc32(data, crc=0, /). The \ is useful, it indicates that you cannot use keywords. If you want to drop \, modify the function to accept keywords. ___ Python-Dev mailing list [email protected] https://mail.python.org/mailman/listinfo/python-dev Unsubscribe: https://mail.python.org/mailman/options/python-dev/archive%40mail-archive.com
Re: [Python-Dev] Needed reviews
On 19 March 2015 at 19:28, Serhiy Storchaka wrote: > Here is list of my ready for review patches. It is incomplete and contains > only patches for which I don't expect objections or long discussion. Most > of them are relative easy and need only formal review. Most of them wait > for a review many months. It's worth noting that If there are changes you feel are genuinely low risk, you can go ahead and merge them based on your own commit review (even if you also wrote the original patch). It's far from ideal, but also a pragmatic recognition of how low the available amount of core developer time we have is relative to the amount of work that *could* be done :( The only time that guideline doesn't apply is if the release manager declares mandatory commit reviews while preparing a release, and I think Larry uses a release branch for that these days instead. Regards, Nick. -- Nick Coghlan | [email protected] | Brisbane, Australia ___ Python-Dev mailing list [email protected] https://mail.python.org/mailman/listinfo/python-dev Unsubscribe: https://mail.python.org/mailman/options/python-dev/archive%40mail-archive.com
Re: [Python-Dev] Use ptyhon -s as default shbang for system python executables/daemons
On 19 March 2015 at 02:48, Barry Warsaw wrote: > It's never gotten much farther than musings, but protecting the system against > the weird things people install would be a good thing. OTOH, this feels a lot > like virtual environments so maybe there's something useful to be mined there. I took it a fair bit further than musings: https://www.python.org/dev/peps/pep-0432/#a-system-python-executable Unfortunately PEP 432's a big project with very high barriers to entry (you need to come to grips with the current arcane startup sequence first), so I've never managed to hand it over after running out of time to pursue it myself. Cheers, Nick. -- Nick Coghlan | [email protected] | Brisbane, Australia ___ Python-Dev mailing list [email protected] https://mail.python.org/mailman/listinfo/python-dev Unsubscribe: https://mail.python.org/mailman/options/python-dev/archive%40mail-archive.com
Re: [Python-Dev] Use ptyhon -s as default shbang for system python executables/daemons
On 19 March 2015 at 07:51, Donald Stufft wrote: > I’ve long wished that the OS had it’s own virtual environment. A lot of > problems > seems to come from trying to cram the things the OS wants with the things that > the user wants into the same namespace. I'm more wanting to go in the other direction and suggest to folks that if they're not *scripting the OS*, then the system Python isn't what they want, and they should be using at least a virtual environment, preferably an entirely separate software collection that they can upgrade on their own timeline, independently of what they system does. Cheers, Nick. -- Nick Coghlan | [email protected] | Brisbane, Australia ___ Python-Dev mailing list [email protected] https://mail.python.org/mailman/listinfo/python-dev Unsubscribe: https://mail.python.org/mailman/options/python-dev/archive%40mail-archive.com
Re: [Python-Dev] super() does not work during class initialization
On 21 March 2015 at 00:03, Martin Teichmann wrote: > The current python fails the assertion, while with my patch everything is > fine, > and I personally think __class__ should always actually refer to the class > being > defined, which means at the minimum that it is actually, well, a class. For folks that haven't looked at the tracker issue: I personally like the change, but it does involve storing the cell object in a dunder-variable in the class namespace while it's being defined (until type.__new__ executes and both populates it and removes it from the class namespace). Since it introduces new behaviour that's visible to Python level code, I've suggested that Martin roll the suggestion into his current PEP 487 (which adds __init_subclass__ to similarly tidy up a few challenges with the way classes are currently initialised). Cheers, Nick. -- Nick Coghlan | [email protected] | Brisbane, Australia ___ Python-Dev mailing list [email protected] https://mail.python.org/mailman/listinfo/python-dev Unsubscribe: https://mail.python.org/mailman/options/python-dev/archive%40mail-archive.com
Re: [Python-Dev] Fwd: class os.DirEntry is confusing,
On 21 March 2015 at 10:15, 罗勇刚(Yonggang Luo) wrote: > -- Forwarded message -- > From: 罗勇刚(Yonggang Luo) > Date: 2015-03-21 2:24 GMT+08:00 > Subject: class os.DirEntry is confusing, > To: Python > > > Should be replaced with os.FsEntry or os.ScanEntry The name comes from the underlying C/POSIX concept (dirent in this case), which is fairly common for the low level APIs in the os module. Cheers, Nick. -- Nick Coghlan | [email protected] | Brisbane, Australia ___ Python-Dev mailing list [email protected] https://mail.python.org/mailman/listinfo/python-dev Unsubscribe: https://mail.python.org/mailman/options/python-dev/archive%40mail-archive.com
Re: [Python-Dev] Use ptyhon -s as default shbang for system python executables/daemons
On Sat, 21 Mar 2015 21:52:34 +1000 Nick Coghlan wrote: > On 19 March 2015 at 07:51, Donald Stufft wrote: > > I’ve long wished that the OS had it’s own virtual environment. A lot of > > problems > > seems to come from trying to cram the things the OS wants with the things > > that > > the user wants into the same namespace. > > I'm more wanting to go in the other direction and suggest to folks > that if they're not *scripting the OS*, then the system Python isn't > what they want, and they should be using at least a virtual > environment, So that defeats the whole point of having a system distribution. I don't have any stakes in Debian / RedHat etc., but that sounds a little bit ridiculous to me ;-) On the other hand, perhaps it would allow ditching any requests to keep code compatible with old versions such as 2.6. Regards Antoine. ___ Python-Dev mailing list [email protected] https://mail.python.org/mailman/listinfo/python-dev Unsubscribe: https://mail.python.org/mailman/options/python-dev/archive%40mail-archive.com
Re: [Python-Dev] Final call for PEP 488: eliminating PYO files
Thanks! PEP 488 is now marked as accepted. I expect I will have PEP 488
implemented before the PyCon sprints are over (work will be tracked in
http://bugs.python.org/issue23731).
On Fri, Mar 20, 2015 at 8:06 PM Guido van Rossum wrote:
> Awesome, that's what I was hoping. Accepted! Congrats and thank you very
> much for writing the PEP and guiding the discussion.
>
> On Fri, Mar 20, 2015 at 4:00 PM, Brett Cannon wrote:
>
>>
>>
>> On Fri, Mar 20, 2015 at 4:41 PM Guido van Rossum
>> wrote:
>>
>>> I am willing to be the BDFL for this PEP. I have tried to skim the
>>> recent discussion (only python-dev) and I don't see much remaining
>>> controversy. HOWEVER... The PEP is not clear (or at least too subtle) about
>>> the actual name for optimization level 0. If I have foo.py, and I compile
>>> it three times with three different optimization levels (no optimization;
>>> -O; -OO), and then I look in __pycache__, would I see this:
>>>
>>> # (1)
>>> foo.cpython-35.pyc
>>> foo.cpython-35.opt-1.pyc
>>> foo.cpython-35.opt-2.pyc
>>>
>>> Or would I see this?
>>>
>>> # (2)
>>> foo.cpython-35.opt-0.pyc
>>> foo.cpython-35.opt-1.pyc
>>> foo.cpython-35.opt-2.pyc
>>>
>>
>> #1
>>
>>
>>>
>>> Your lead-in ("I have decided to have the default case of no
>>> optimization levels mean that the .pyc file name will have *no* optimization
>>> level specified in the name and thus be just as it is today.") makes me
>>> think I should expect (1), but I can't actually pinpoint where the language
>>> of the PEP says this.
>>>
>>
>> It was meant to be explained by "When no optimization level is
>> specified, the pre-PEP ``.pyc`` file name will be used (i.e., no change
>> in file name
>> semantics)", but obviously it's a bit too subtle. I just updated the PEP
>> with an explicit list of bytecode file name examples based on no -O, -O,
>> and -OO.
>>
>> -Brett
>>
>>
>>>
>>>
>>> On Fri, Mar 20, 2015 at 11:34 AM, Brett Cannon
>>> wrote:
>>>
I have decided to have the default case of no optimization levels mean
that the .pyc file name will have *no* optimization level specified in
the name and thus be just as it is today. I made this decision due to
potential backwards-compatibility issues -- although I expect them to be
minutes -- and to not force other implementations like PyPy to have some
bogus value set since they don't have .pyo files to begin with (PyPy
actually uses bytecode for -O and don't bother with -OO since PyPy already
uses a bunch of memory when running).
Since this closes out the last open issue, I need either a BDFL
decision or a BDFAP to be assigned to make a decision. Guido?
==
PEP: 488
Title: Elimination of PYO files
Version: $Revision$
Last-Modified: $Date$
Author: Brett Cannon
Status: Draft
Type: Standards Track
Content-Type: text/x-rst
Created: 20-Feb-2015
Post-History:
2015-03-06
2015-03-13
2015-03-20
Abstract
This PEP proposes eliminating the concept of PYO files from Python.
To continue the support of the separation of bytecode files based on
their optimization level, this PEP proposes extending the PYC file
name to include the optimization level in the bytecode repository
directory when it's called for (i.e., the ``__pycache__`` directory).
Rationale
=
As of today, bytecode files come in two flavours: PYC and PYO. A PYC
file is the bytecode file generated and read from when no
optimization level is specified at interpreter startup (i.e., ``-O``
is not specified). A PYO file represents the bytecode file that is
read/written when **any** optimization level is specified (i.e., when
``-O`` **or** ``-OO`` is specified). This means that while PYC
files clearly delineate the optimization level used when they were
generated -- namely no optimizations beyond the peepholer -- the same
is not true for PYO files. To put this in terms of optimization
levels and the file extension:
- 0: ``.pyc``
- 1 (``-O``): ``.pyo``
- 2 (``-OO``): ``.pyo``
The reuse of the ``.pyo`` file extension for both level 1 and 2
optimizations means that there is no clear way to tell what
optimization level was used to generate the bytecode file. In terms
of reading PYO files, this can lead to an interpreter using a mixture
of optimization levels with its code if the user was not careful to
make sure all PYO files were generated using the same optimization
level (typically done by blindly deleting all PYO files and then
using the `compileall` module to compile all-new PYO files [1]_).
This issue is only compounded when people optimize Python code beyond
what the interpreter natively supports, e.g., using the astoptimizer
project [2]_.
In terms
Re: [Python-Dev] Use ptyhon -s as default shbang for system python executables/daemons
On 21 March 2015 at 22:19, Antoine Pitrou wrote: > On Sat, 21 Mar 2015 21:52:34 +1000 > Nick Coghlan wrote: >> On 19 March 2015 at 07:51, Donald Stufft wrote: >> > I’ve long wished that the OS had it’s own virtual environment. A lot of >> > problems >> > seems to come from trying to cram the things the OS wants with the things >> > that >> > the user wants into the same namespace. >> >> I'm more wanting to go in the other direction and suggest to folks >> that if they're not *scripting the OS*, then the system Python isn't >> what they want, and they should be using at least a virtual >> environment, > > So that defeats the whole point of having a system distribution. Given how many of the operating system packages are written in Python, it really doesn't - system administrators getting to use Python to script the OS is a secondary purpose, the system Python installation is mostly there to make the OS itself work (if it wasn't for that, migrating the system Python to Python 3 would have been a lot simpler!). In my view, running system independent applications in the system Python is at best a tertiary purpose - many of those apps (especially web services) *don't want* to be using system modules at all, which is why virtualenv switched to disabling the global site-packages by default. > I don't have any stakes in Debian / RedHat etc., but that sounds > a little bit ridiculous to me ;-) On the other hand, perhaps it would > allow ditching any requests to keep code compatible with old versions > such as 2.6. That's exactly the reason for the preference - unless they're specifically wanting to script RHEL/CentOS 6 or a similar long term support version at this point, ideally folks should be able to use Python 2.7 as their baseline version by now. RHEL/CentOS 7 are both on 2.7, while Python 2.7 has been available for RHEL/CentOS 6 by way of software collections for a couple of years now. When Python 2 goes EOL upstream in 2020, the standard 10 years of support on RHEL 7 will still have 4 years left to run - I'd prefer to see most folks migrated to a Python 3 software collection by then (or failing that, at least to the Python 3 stack Slavek is aiming to get into EPEL 7). Unfortunately, as far as I am aware, Debian Stable and Ubuntu LTS don't yet have a distro-endorsed equivalent of softwarecollections.org, and it's not yet clear if running on a faster moving base distro in a Docker or Rocket container will be an adequate alternative. I believe SCLs moved over to using Linux environment modules as the backend tech in 2.0 (for compatibility with existing HPC environments), so it should likely be possible to adapt them to work with APT in addition to RPM, but that requires finding folks both interested in doing the technical work, as well as in making the case for SCLs as a feature in the relevant distros (they're a large enough departure from the traditional mode of operation of a Linux distro that it took a long time to find a stable upstream home for the ongoing maintenance of SCLs for the Fedora/RHEL/CentOS ecosystem - primary maintenance responsibility finally landed earlier this year as a CentOS SIG) Regards, Nick. -- Nick Coghlan | [email protected] | Brisbane, Australia ___ Python-Dev mailing list [email protected] https://mail.python.org/mailman/listinfo/python-dev Unsubscribe: https://mail.python.org/mailman/options/python-dev/archive%40mail-archive.com
Re: [Python-Dev] Final call for PEP 488: eliminating PYO files
On Mar 21, 2015 7:44 AM, "Brett Cannon" wrote: > > Thanks! PEP 488 is now marked as accepted. I expect I will have PEP 488 implemented before the PyCon sprints are over (work will be tracked in http://bugs.python.org/issue23731). > > On Fri, Mar 20, 2015 at 8:06 PM Guido van Rossum wrote: >> >> Awesome, that's what I was hoping. Accepted! Congrats and thank you very much for writing the PEP and guiding the discussion. Congratulations Brett! This is a welcome change. I'll be sure to give you a review. -eric ___ Python-Dev mailing list [email protected] https://mail.python.org/mailman/listinfo/python-dev Unsubscribe: https://mail.python.org/mailman/options/python-dev/archive%40mail-archive.com
Re: [Python-Dev] Use ptyhon -s as default shbang for system python executables/daemons
> On Mar 21, 2015, at 7:52 AM, Nick Coghlan wrote: > > On 19 March 2015 at 07:51, Donald Stufft wrote: >> I’ve long wished that the OS had it’s own virtual environment. A lot of >> problems >> seems to come from trying to cram the things the OS wants with the things >> that >> the user wants into the same namespace. > > I'm more wanting to go in the other direction and suggest to folks > that if they're not *scripting the OS*, then the system Python isn't > what they want, and they should be using at least a virtual > environment, preferably an entirely separate software collection that > they can upgrade on their own timeline, independently of what they > system does. > It’s likely easier to get the OS to move it’s own things to a virtual environment than it is to convince every single person who uses an OS to never install globally. --- Donald Stufft PGP: 7C6B 7C5D 5E2B 6356 A926 F04F 6E3C BCE9 3372 DCFA signature.asc Description: Message signed with OpenPGP using GPGMail ___ Python-Dev mailing list [email protected] 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 document functions with optional positional parameters?
On 3/21/2015 12:41 AM, Serhiy Storchaka wrote: How to document functions with optional positional parameters? For example binascii.crc32(). It has two positional parameters, one is mandatory, and one is optional with default value 0. With Argument Clinic its signature is crc32(data, crc=0, /). In the documentation it is written as crc32(data[, crc]) (and noted that the default value of the second parameter is 0). Both are not valid Python syntax. Can the documentation be change to crc32(data, crc=0)? I think the docs should be using / as well. Related issues: https://bugs.python.org/issue21488 (changed encode(obj, encoding='ascii', errors='strict') to encode(obj, [encoding[, errors]])) https://bugs.python.org/issue22832 (changed ioctl(fd, op[, arg[, mutate_flag]]) to ioctl(fd, request, arg=0, mutate_flag=True)) https://bugs.python.org/issue22341 (discussed changing crc32(data[, crc]) to crc32(data, crc=0)) -- Terry Jan Reedy ___ Python-Dev mailing list [email protected] https://mail.python.org/mailman/listinfo/python-dev Unsubscribe: https://mail.python.org/mailman/options/python-dev/archive%40mail-archive.com
Re: [Python-Dev] some minor questions about pep8
On Mar 20, 2015, at 08:53 PM, Guido van Rossum wrote: >FWIW, I think __version__, __author__ etc. were bad ideas. Almost nobody >manages these correctly. Note that the PEP 8 section starts with less than >an endorsement: "If you *have* to have Subversion, CVS, or RCS crud in your >source file, do it as follows." I tend to agree. Individual module version numbers are mostly useless, especially with today's hash-based vcses. That's different than package versions, and for which I really need to resurrect and update PEP 396. >That said, if an official answer is required, common sense would suggest >that __version__ should go before the imports. (I would put it before the >docstring too, except then the docstring wouldn't be a docstring any more. >Go figure.) And after __future__ imports too, right? Cheers, -Barry ___ Python-Dev mailing list [email protected] https://mail.python.org/mailman/listinfo/python-dev Unsubscribe: https://mail.python.org/mailman/options/python-dev/archive%40mail-archive.com
Re: [Python-Dev] some minor questions about pep8
On Mar 20, 2015, at 09:59 PM, Ian Lee wrote: >shebang >docstring >imports >dunder assignments >other code... I generally put imports after dunders, except for __future__. I want the first screenful of code to contain them, and imports can be a few dozen lines in some modules. -Barry ___ Python-Dev mailing list [email protected] https://mail.python.org/mailman/listinfo/python-dev Unsubscribe: https://mail.python.org/mailman/options/python-dev/archive%40mail-archive.com
[Python-Dev] Google Summer of Code
Jython plans to participate in the Google Summer of Code for 2015. If you
are interested, I have outlined a number of projects on our ideas page that
students could work on:
- Work on JyNI, which adds C extension API support to Jython
- Performance optimizations, including startup time
- Python bytecode compiler for Python source (must be written in Java!)
See https://github.com/jythontools/gsoc2015 for the ideas page. Pull
requests and comments gladly accepted to expand this list of ideas.
The ideal student must be a very strong Java developer, with an existing
track record of projects on such sites as GitHub and BitBucket. Knowledge
of C and especially of the CPython source code invariably helps. Ideally
you will also become a Jython committer as a result of your intense
participation this summer.
Note that the deadline for student proposals is very soon, Friday March 27.
I apologize we are just getting our participation for GSOC together, but we
have also been busy finalizing the Jython 2.7.0 release candidate.
--
- Jim
jim.baker@{colorado.edu|python.org|rackspace.com|zyasoft.com}
twitter.com/jimbaker
github.com/jimbaker
bitbucket.com/jimbaker
___
Python-Dev mailing list
[email protected]
https://mail.python.org/mailman/listinfo/python-dev
Unsubscribe:
https://mail.python.org/mailman/options/python-dev/archive%40mail-archive.com
Re: [Python-Dev] some minor questions about pep8
> On Mar 21, 2015, at 4:53 PM, Barry Warsaw wrote: > > On Mar 20, 2015, at 08:53 PM, Guido van Rossum wrote: > >> FWIW, I think __version__, __author__ etc. were bad ideas. Almost nobody >> manages these correctly. Note that the PEP 8 section starts with less than >> an endorsement: "If you *have* to have Subversion, CVS, or RCS crud in your >> source file, do it as follows." > > I tend to agree. Individual module version numbers are mostly useless, > especially with today's hash-based vcses. > > That's different than package versions, and for which I really need to > resurrect and update PEP 396. I sort of think (though I haven’t completely convinced myself) that adding something like __version__ to a package is a work around to the fact that we don’t have an API that lets someone ask “what is the distribution and version that this module/import-package came from”. Something like: >>> import theorticalapi >>> import mymodule >>> >>> d = theorticalapi.module_dist(mymodule) >>> print(d.name) >>> mycustommodules >>> print(d.version) >>> 1.0 Since we (theoretically) should have all of this information already inside of the packaging metadata, we just don’t have a way to say “given a particular import, give me the information I want). > >> That said, if an official answer is required, common sense would suggest >> that __version__ should go before the imports. (I would put it before the >> docstring too, except then the docstring wouldn't be a docstring any more. >> Go figure.) > > And after __future__ imports too, right? > > Cheers, > -Barry > ___ > Python-Dev mailing list > [email protected] > https://mail.python.org/mailman/listinfo/python-dev > Unsubscribe: > https://mail.python.org/mailman/options/python-dev/donald%40stufft.io --- Donald Stufft PGP: 7C6B 7C5D 5E2B 6356 A926 F04F 6E3C BCE9 3372 DCFA signature.asc Description: Message signed with OpenPGP using GPGMail ___ Python-Dev mailing list [email protected] https://mail.python.org/mailman/listinfo/python-dev Unsubscribe: https://mail.python.org/mailman/options/python-dev/archive%40mail-archive.com
Re: [Python-Dev] Missing *-unpacking generalizations (issue 2292)
On Fri, Mar 20, 2015, at 19:16, Neil Girdhar wrote: > Wow, this is an excellent review. Thank you. > > My only question is with respect to this: > > I think there ought to be two opcodes; one for unpacking maps in > function calls and another for literals. The whole function location > thing is rather hideous. > > What are the two opcodes? BUILD_MAP_UNPACK and > BUILD_MAP_UNPACK_WITH_CALL? > > The first takes (n) a number of maps that it will merge, and the second > does the same but also accepts (function_call_location) for the purpose > of > error reporting? Exactly. ___ Python-Dev mailing list [email protected] https://mail.python.org/mailman/listinfo/python-dev Unsubscribe: https://mail.python.org/mailman/options/python-dev/archive%40mail-archive.com
Re: [Python-Dev] some minor questions about pep8
On 2015-03-21 21:00, Donald Stufft wrote: On Mar 21, 2015, at 4:53 PM, Barry Warsaw wrote: On Mar 20, 2015, at 08:53 PM, Guido van Rossum wrote: FWIW, I think __version__, __author__ etc. were bad ideas. Almost nobody manages these correctly. Note that the PEP 8 section starts with less than an endorsement: "If you *have* to have Subversion, CVS, or RCS crud in your source file, do it as follows." I tend to agree. Individual module version numbers are mostly useless, especially with today's hash-based vcses. That's different than package versions, and for which I really need to resurrect and update PEP 396. I sort of think (though I haven’t completely convinced myself) that adding something like __version__ to a package is a work around to the fact that we don’t have an API that lets someone ask “what is the distribution and version that this module/import-package came from”. Something like: >>> import theorticalapi >>> import mymodule >>> >>> d = theorticalapi.module_dist(mymodule) >>> print(d.name) >>> mycustommodules >>> print(d.version) >>> 1.0 Since we (theoretically) should have all of this information already inside of the packaging metadata, we just don’t have a way to say “given a particular import, give me the information I want). A bit OT (and should probably be in python-ideas), but I've come to think that it might be more helpful to have double version numbers. What do I mean by that? Well, an "addition" version that's increased when something is added, and a "deletion" version that's increased when something is removed. Suppose there's a new release of a module. If it has a higher "addition version", then something has been added, which won't affect existing code. If it has a higher "deletion version", then something has been removed, which _might_ affect existing code, so you'll need to check. If the code doesn't use what was removed, then you can accept the higher deletion version. That said, if an official answer is required, common sense would suggest that __version__ should go before the imports. (I would put it before the docstring too, except then the docstring wouldn't be a docstring any more. Go figure.) And after __future__ imports too, right? ___ Python-Dev mailing list [email protected] https://mail.python.org/mailman/listinfo/python-dev Unsubscribe: https://mail.python.org/mailman/options/python-dev/archive%40mail-archive.com
Re: [Python-Dev] some minor questions about pep8
> On Mar 21, 2015, at 5:17 PM, MRAB wrote: > > On 2015-03-21 21:00, Donald Stufft wrote: >> >>> On Mar 21, 2015, at 4:53 PM, Barry Warsaw wrote: >>> >>> On Mar 20, 2015, at 08:53 PM, Guido van Rossum wrote: >>> FWIW, I think __version__, __author__ etc. were bad ideas. Almost nobody manages these correctly. Note that the PEP 8 section starts with less than an endorsement: "If you *have* to have Subversion, CVS, or RCS crud in your source file, do it as follows." >>> >>> I tend to agree. Individual module version numbers are mostly useless, >>> especially with today's hash-based vcses. >>> >>> That's different than package versions, and for which I really need to >>> resurrect and update PEP 396. >> >> I sort of think (though I haven’t completely convinced myself) that adding >> something like __version__ to a package is a work around to the fact that >> we don’t have an API that lets someone ask “what is the distribution and >> version that this module/import-package came from”. >> >> Something like: >> >> >>> import theorticalapi >> >>> import mymodule >> >>> >> >>> d = theorticalapi.module_dist(mymodule) >> >>> print(d.name) >> >>> mycustommodules >> >>> print(d.version) >> >>> 1.0 >> >> Since we (theoretically) should have all of this information already inside >> of the packaging metadata, we just don’t have a way to say “given a >> particular >> import, give me the information I want). >> > A bit OT (and should probably be in python-ideas), but I've come to think > that it might be more helpful to have double version numbers. > > What do I mean by that? > > Well, an "addition" version that's increased when something is added, and a > "deletion" version that's increased when something is removed. > > Suppose there's a new release of a module. > > If it has a higher "addition version", then something has been added, which > won't affect existing code. > > If it has a higher "deletion version", then something has been removed, which > _might_ affect existing code, so you'll need to check. If the code doesn't > use what was removed, then you can accept the higher deletion version. This is likely better solved by something like https://semver.org/ which is similar to what many people do already: X.Y.Z+1 == Bug fixes only, should be backwards compatible. X.Y+1.0 == New features, should be backwards compatible but comes with new things. X+1.0.0 == Backwards Compatibility Break (Something deleted or changed) > >>> That said, if an official answer is required, common sense would suggest that __version__ should go before the imports. (I would put it before the docstring too, except then the docstring wouldn't be a docstring any more. Go figure.) >>> >>> And after __future__ imports too, right? >>> > > ___ > Python-Dev mailing list > [email protected] > https://mail.python.org/mailman/listinfo/python-dev > Unsubscribe: > https://mail.python.org/mailman/options/python-dev/donald%40stufft.io --- Donald Stufft PGP: 7C6B 7C5D 5E2B 6356 A926 F04F 6E3C BCE9 3372 DCFA signature.asc Description: Message signed with OpenPGP using GPGMail ___ Python-Dev mailing list [email protected] https://mail.python.org/mailman/listinfo/python-dev Unsubscribe: https://mail.python.org/mailman/options/python-dev/archive%40mail-archive.com
Re: [Python-Dev] some minor questions about pep8
On Mar 21, 2015, at 05:00 PM, Donald Stufft wrote: >I sort of think (though I haven’t completely convinced myself) that adding >something like __version__ to a package is a work around to the fact that >we don’t have an API that lets someone ask “what is the distribution and >version that this module/import-package came from”. I tend to agree. Having that would solve one of the big problems that lead to PEP 394 thinking, that of having to update version numbers in more than one place. ISTM the best place to do it is once in setup.py and let the metadata flow. The only downside is for doing in-tree development without 'installing' the package (e.g. absence of venv, tox, or similar). Cheers, -Barry pgpMGj2h7VWfU.pgp Description: OpenPGP digital signature ___ Python-Dev mailing list [email protected] https://mail.python.org/mailman/listinfo/python-dev Unsubscribe: https://mail.python.org/mailman/options/python-dev/archive%40mail-archive.com
[Python-Dev] 0-base and 1-base indexed iterables? Custom slicing rules?
Hi, I'm an Art and CG student learning Python and today's exercise was
about positions in a tiled room. The fact that I had to check if a position
was inside the room and given that in a 1x1 room, 0.0 was considered in and
1.0 was considered out, it kept me thinking about 0-base indexing iterables
and slicing.
Read some articles and discussions, some pros and cons to each 0-base and
1-base, concerns about slicing, etc. But ultimately the question that got
stuck in me and didn't found an answer was:
Why can't both 0-base and 1-base indexing exist in the same language, and
why can't slicing be customized?
If I'm indexing the ruler marks, intervals, boundaries, dots, makes sense
to start of at 0; rul=[0,1,2,3,4,5,6] would index every mark on my ruler so
that accordingly rul[0]=0, rul[5]=5.
If I'm indexing the blue circles, natural number quantities, objects,
spans, makes sense to start at 1; cir= [1,2,3,4,5] so that cir[1]=1 and
cir[5]=5.
Now, a lot of the discussion was to do with slicing coupled with the
indexing and I don't totally understand why.
a ≤ x < b is not so intuitive when dealing with objects ("I want balls 1 up
to the the one before 3"), so on one side, you put the finger on what you
want and on the other, on what you don't want. But this method does have
the neat property of producing neighbor selections that border perfectly,
as in [:a][a:b][b:c]. Although in inverse order(-1), the results can be
unexpected as it returns values off-by-one from its counterpart like;
L=[0,1,2,3,4,5] so that L[1:3]=[1,2] and L[3:1:-1]=[3:2]. So it's
consistent with the rule a ≤ x < b, grabbing the lower limit item, but it
can feel strange by not producing the same selection with inverse order.
a ≤ x ≤ b is a natural way to select objets ("I want the balls 1 up to 3"),
so you're putting the finger on the things you want. If you inverse the
order(-1) it's still very easy to grasp what are you picking because
whatever you select it's included like: L=[0,1,2,3,4,5] so that
L[1:3]=[1,2,3] and L[3:1:-1]=[3,2,1]. Problems seem to arrive though, when
trying to do neighbor selections, where one would have to do
[:a][a+1:b][b+1:c] to have the border perfectly. That terrible?
Even though one could see a ≤ x < b to be more adept to 0-base, and a ≤ x ≤
b to be more adept to 1-base, the way I see it, index base and slicing
rules could be somehow independent. And one would index and slice the way
it would fit the rationale of the problem or the data, because even slicing
a 1-base indexed array with a ≤ x < b, would still produce an expected
outcome, as in cir=[1,2,3,4,5] so that cir[1:3]=[1,2] or cir[:3]=[1,2].
Same thing applying a ≤ x ≤ b to a 0-base indexed array, as in
rul[0,1,2,3,4,5] so that rul[:2]=[0,1,2] or rul[0:2]=[0,1,2].
Given that python is an example of human friendly code language,
emphasizing readability, wouldn't having 0 and 1 base indexing and custom
slicing methods, improve the thought process when writing and reading the
code, by fitting them better to specific contexts or data?
Is there some language that provides both or each language picks only one?
Cheers
--
*--[image:
http://i153.photobucket.com/albums/s202/animatics/probiner-sig.gif]Pedro
Alpiarça dos Santos Animator 3DModeler Illustrator >>
http://probiner.x10.mx/
Re: [Python-Dev] How to document functions with optional positional parameters?
On 22 March 2015 at 04:47, Terry Reedy wrote: > On 3/21/2015 12:41 AM, Serhiy Storchaka wrote: >> >> How to document functions with optional positional parameters? >> >> For example binascii.crc32(). It has two positional parameters, one is >> mandatory, and one is optional with default value 0. With Argument >> Clinic its signature is crc32(data, crc=0, /). In the documentation it >> is written as crc32(data[, crc]) (and noted that the default value of >> the second parameter is 0). Both are not valid Python syntax. Can the >> documentation be change to crc32(data, crc=0)? > > > I think the docs should be using / as well. Right, even though the Python level parser doesn't allow this syntax, it's the one used by Argument Clinic to express positional-only parameters for functions defined in C, and as a result the inspect module uses it as well: >>> import inspect >>> print(inspect.signature(hex)) (number, /) This is the specific problem Larry was aiming to address in https://www.python.org/dev/peps/pep-0457/ - getting the docs, Argument Clinic and the inspect module to align in their notation, even though he wasn't proposing to change Python itself to allow positional-only parameter definitions. Cheers, Nick. -- Nick Coghlan | [email protected] | Brisbane, Australia ___ Python-Dev mailing list [email protected] https://mail.python.org/mailman/listinfo/python-dev Unsubscribe: https://mail.python.org/mailman/options/python-dev/archive%40mail-archive.com
Re: [Python-Dev] 0-base and 1-base indexed iterables? Custom slicing rules?
On 3/21/2015 10:46 PM, pedro santos wrote: Hi, I'm an Art and CG student learning Python and today's exercise was about positions in a tiled room. The fact that I had to check if a position was inside the room and given that in a 1x1 room, 0.0 was considered in and 1.0 was considered out, it kept me thinking about 0-base indexing iterables and slicing. This sort of discussion is better held on [email protected] which is for learning and using the current and past versions of Python. This mailing list is for coordinating the development of future versions of Python. If your idea is to start a discussion to attempt to affect future versions of Python, that sort of discussion belongs on [email protected], and ideas that are appropriate for implementation in future versions of Python eventually come to python-dev when they are accepted for implementation. There are lots of friendly people on all these lists, but it is best to use the correct one, so that people can focus on the intended topics of the lists when reading each of them. Cheers! ___ Python-Dev mailing list [email protected] https://mail.python.org/mailman/listinfo/python-dev Unsubscribe: https://mail.python.org/mailman/options/python-dev/archive%40mail-archive.com
Re: [Python-Dev] some minor questions about pep8
On 22 March 2015 at 07:46, Barry Warsaw wrote: > On Mar 21, 2015, at 05:00 PM, Donald Stufft wrote: > >>I sort of think (though I haven’t completely convinced myself) that adding >>something like __version__ to a package is a work around to the fact that >>we don’t have an API that lets someone ask “what is the distribution and >>version that this module/import-package came from”. > > I tend to agree. Having that would solve one of the big problems that lead to > PEP 394 thinking, that of having to update version numbers in more than one > place. ISTM the best place to do it is once in setup.py and let the metadata > flow. The only downside is for doing in-tree development without 'installing' > the package (e.g. absence of venv, tox, or similar). We don't *quite* track enough distribution metadata currently to reliably build the reverse mapping from module names to the packages that installed them. The draft "python.exports" extension in PEP 459 is supposed to provide that missing piece: https://www.python.org/dev/peps/pep-0459/#the-python-exports-extension Cheers, Nick. -- Nick Coghlan | [email protected] | Brisbane, Australia ___ Python-Dev mailing list [email protected] https://mail.python.org/mailman/listinfo/python-dev Unsubscribe: https://mail.python.org/mailman/options/python-dev/archive%40mail-archive.com
