On Tue, 27 Apr 2021 at 18:01, Brett Cannon wrote:
> Unfortunately I thought importlib.metadata would have used the module name
> instead of the metadata details, but in hindsight am guessing that the
> .dist-info is what it's using to do the lookup and that's based on the
> package name
On Mon, Apr 26, 2021 at 3:25 PM Stestagg wrote:
>
>
> On Mon, Apr 26, 2021 at 10:31 PM Brett Cannon wrote:
>
>>
>>
>> On Mon, Apr 26, 2021 at 9:37 AM Baptiste Carvello <
>> devel2...@baptiste-carvello.net> wrote:
>>
>>> Hi,
>>>
>>> sorry for being late to the party, but I may not be the only
On Mon, Apr 26, 2021 at 10:31 PM Brett Cannon wrote:
>
>
> On Mon, Apr 26, 2021 at 9:37 AM Baptiste Carvello <
> devel2...@baptiste-carvello.net> wrote:
>
>> Hi,
>>
>> sorry for being late to the party, but I may not be the only one
>> wondering…
>>
>> Le 14/04/2021 à 20:56, Barry Warsaw a écrit
On Mon, Apr 26, 2021 at 9:37 AM Baptiste Carvello <
devel2...@baptiste-carvello.net> wrote:
> Hi,
>
> sorry for being late to the party, but I may not be the only one wondering…
>
> Le 14/04/2021 à 20:56, Barry Warsaw a écrit :
> >
> > I’d forgotten that this PEP was in Deferred state. I think
Hi,
sorry for being late to the party, but I may not be the only one wondering…
Le 14/04/2021 à 20:56, Barry Warsaw a écrit :
>
> I’d forgotten that this PEP was in Deferred state. I think it should be
> rejected and I plan on making that change. importlib.metadata is a much
> better
On Thu, 15 Apr 2021 16:12:57 -0700
Brett Cannon wrote:
>
> So I don't think version comparison occurs often enough to be in the
> stdlib, and the fact that an external project exists which isn't interested
> in being put in the stdlib suggests to me it isn't worth doing.
>
> But that's a
On Thu, Apr 15, 2021 at 10:53 AM Antoine Pitrou wrote:
> On Thu, 15 Apr 2021 10:28:53 -0700
> Brett Cannon wrote:
> > On Thu, Apr 15, 2021 at 8:50 AM Christopher Barker
> > wrote:
> >
> > > On Thu, Apr 15, 2021 at 2:40 AM Victor Stinner
> > > wrote:
> > >
> > >> Paul Bryan:
> > >> > Seems
Replying to myself to update my own thoughts:
I think __version__ and packaging tools answer separate questions.
__version__ answers the question of "this module I imported, what
version is it".
The packaging tools answer the question "what dependency does this
distribution satisfy".
This
On Thu, 15 Apr 2021 at 21:03, Christopher Barker wrote:
> I am leaning toward at least SOME PEP about this -- having __version__
> around as a semi-convention with no official recommendation as to if or how
> it should be used is kind of a mess.
On the other hand, having a PEP that says you
On Thu, Apr 15, 2021 at 9:54 PM Christopher Barker
wrote:
> Or rather, the below is what I would find really nice to be able to do.
>
>> ver = robust_version(module)
>> if ver >= (5, 2, 1):
>> doit_modern_style()
>> elif ver < (5, 2, 1):
>> doit_old_style
>> else:
>>
On Thu, Apr 15, 2021 at 9:36 AM David Mertz wrote:
> I was so hopeful about this, but in the end... not really. I have not
> used this capability before. Here are a few different situations I know of:
>
...
...
re PackageNotFoundError('re')
statistics PackageNotFoundError('statistics')
On Thu, Apr 15, 2021 at 12:27 PM Terry Reedy wrote:
> At least some in the stdlib have not been. For re.__version__, not
> since Nov 2001.
>
>From Serhiy over on python-ideas, he's started an effort to clean that up.
On Thu, Apr 15, 2021 at 9:38 AM Barry Warsaw wrote:
> From a library maintainers point of view, I personally want to get away
> from using __version__ strings at all. They’re kind of a pain to remember
> to bump on every new release.
That’s a tooling issue, and I don’t think that Python
On 4/15/2021 12:35 PM, David Mertz wrote:
re 2.2.1
re.__version__ was last modified 2001-10-07 by F. Lundh in
bec95b9d8825b39cff46a8c645fa0eeb8409854e. What does '2.2.1' mean? Only
Fredrik knows. The commit message says that he rewrote the pattern.sub
and pattern.subn methods in C.
On 4/15/2021 12:38 PM, Barry Warsaw wrote:
On Apr 14, 2021, at 23:11, Christopher Barker wrote:
You wrote the original PEP, so of course you can withdraw it (or reject it),
but...
Are you sure? See this discussion, I don't think it's as simple as all
that.
From a library maintainers
Replying to the original email because my comment is more a thought
after reading the whole thread rather than a response to any
particular message.
What I love about __version__ is that it is simple. It doesn't come
with the complexity of solutions like `importlib.metadata.version`.
The
On Apr 15, 2021, at 09:54, Antoine Pitrou wrote:
>
> On Thu, 15 Apr 2021 09:38:41 -0700
> Barry Warsaw wrote:
>> On Apr 14, 2021, at 23:11, Christopher Barker wrote:
>>>
>>> You wrote the original PEP, so of course you can withdraw it (or reject
>>> it), but...
>>>
>>> Are you sure? See
On Thu, 15 Apr 2021 10:28:53 -0700
Brett Cannon wrote:
> On Thu, Apr 15, 2021 at 8:50 AM Christopher Barker
> wrote:
>
> > On Thu, Apr 15, 2021 at 2:40 AM Victor Stinner
> > wrote:
> >
> >> Paul Bryan:
> >> > Seems like this is something that should make its way into stdlib?
> >>
> >> In
On Thu, Apr 15, 2021 at 8:50 AM Christopher Barker
wrote:
> On Thu, Apr 15, 2021 at 2:40 AM Victor Stinner
> wrote:
>
>> Paul Bryan:
>> > Seems like this is something that should make its way into stdlib?
>>
>> In the last 10 years, the trend is more to remove anything related to
>> packaging
On Thu, Apr 15, 2021 at 9:36 AM David Mertz wrote:
> On Thu, Apr 15, 2021 at 4:55 PM Christopher Barker
> wrote:
>
>> Presumably that's why importlib.metadata exists in the stdlib.
>>
>
> I was so hopeful about this, but in the end... not really. I have not
> used this capability before. Here
On Thu, 15 Apr 2021 09:38:41 -0700
Barry Warsaw wrote:
> On Apr 14, 2021, at 23:11, Christopher Barker wrote:
> >
> > You wrote the original PEP, so of course you can withdraw it (or reject
> > it), but...
> >
> > Are you sure? See this discussion, I don't think it's as simple as all
> >
On Apr 14, 2021, at 23:11, Christopher Barker wrote:
>
> You wrote the original PEP, so of course you can withdraw it (or reject it),
> but...
>
> Are you sure? See this discussion, I don't think it's as simple as all that.
From a library maintainers point of view, I personally want to get
On Thu, Apr 15, 2021 at 4:55 PM Christopher Barker
wrote:
> Presumably that's why importlib.metadata exists in the stdlib.
>
I was so hopeful about this, but in the end... not really. I have not used
this capability before. Here are a few different situations I know of:
>>> import re,
On Thu, Apr 15, 2021 at 2:40 AM Victor Stinner wrote:
> Paul Bryan:
> > Seems like this is something that should make its way into stdlib?
>
> In the last 10 years, the trend is more to remove anything related to
> packaging *outside* the stdlib :-)
Well, maybe all of us don't think that's a
On Thu, 15 Apr 2021 11:37:28 +0200
Victor Stinner wrote:
> Paul Bryan:
> > Seems like this is something that should make its way into stdlib?
>
> In the last 10 years, the trend is more to remove anything related to
> packaging *outside* the stdlib :-) Since it's evolving way faster
What is
Paul Bryan:
> Seems like this is something that should make its way into stdlib?
In the last 10 years, the trend is more to remove anything related to
packaging *outside* the stdlib :-) Since it's evolving way faster than
Python releases and the stdlib cannot be updated once installed, I
don't
On Wed, Apr 14, 2021 at 2:23 PM Paul Moore wrote:
> >> because PEP 440 versions are fundamental to packaging.
> >
> > Are you suggesting that users should have to install an external module
> to tell what version of packages they are using?!
>
> No. To tell what version of a package they are
On Wed, Apr 14, 2021 at 12:10 PM Barry Warsaw wrote:
I’d forgotten that this PEP was in Deferred state. I think it should be
> rejected and I plan on making that change. importlib.metadata is a much
> better approach to programmatically determining package versions.
>
>
>
On Wed, Apr 14, 2021 at 7:04 PM Jim J. Jewett wrote:
> I don't have a deep answer, but I do think __version__ should be specified
> (or at least mentioned) at
> https://docs.python.org/3/reference/datamodel.html
Given the intent to reject PEP 394, I can't imagine any good would come of
that.
https://docs.python.org/3/reference/datamodel.html
On Wed, 2021-04-14 at 22:56 +, Jim J. Jewett wrote:
> Paul Moore wrote:
> > What's wrong with Version(module.__version__)? And if the
> > __version__
> > attribute isn't a valid version, raise an exception?
>
> I don't have a deep answer,
Paul Moore wrote:
> What's wrong with Version(module.__version__)? And if the __version__
> attribute isn't a valid version, raise an exception?
I don't have a deep answer, but I do think __version__ should be specified (or
at least mentioned) at
Seems like this is something that should make its way into stdlib?
On Thu, 2021-04-15 at 00:15 +0200, Antoine Pitrou wrote:
> On Wed, 14 Apr 2021 22:23:44 +0100
> Paul Moore wrote:
> > On Wed, 14 Apr 2021 at 21:59, David Mertz wrote:
> > >
> > > On Wed, Apr 14, 2021 at 9:12 PM Paul Moore
> >
On Wed, 14 Apr 2021 22:23:44 +0100
Paul Moore wrote:
> On Wed, 14 Apr 2021 at 21:59, David Mertz wrote:
> >
> > On Wed, Apr 14, 2021 at 9:12 PM Paul Moore wrote:
> >>
> >> If it's not basically equivalent to packaging.version.Version (and
> >> based on PEP 440) then we'll be creating a
On Wed, 14 Apr 2021 at 21:59, David Mertz wrote:
>
> On Wed, Apr 14, 2021 at 9:12 PM Paul Moore wrote:
>>
>> If it's not basically equivalent to packaging.version.Version (and
>> based on PEP 440) then we'll be creating a nightmare of confusion,
>> because PEP 440 versions are fundamental to
On Wed, Apr 14, 2021 at 9:12 PM Paul Moore wrote:
> If it's not basically equivalent to packaging.version.Version (and
> based on PEP 440) then we'll be creating a nightmare of confusion,
> because PEP 440 versions are fundamental to packaging.
>
Are you suggesting that users should have to
On Wed, Apr 14, 2021 at 4:19 PM Paul Moore wrote:
> PS I see Barry plans on rejecting the PEP, which I think is probably
> the right decision, given the way this thread has developed.
>
Barry makes good plans.
Putting the version into the sources is a bit of an anti-pattern. IMO.
-Fred
On Wed, 14 Apr 2021 at 18:04, Eric V. Smith wrote:
>> Anyway, the question now for me is whether this is worth any more of my time.
>>
>> So:
>> - Is there someone willing to sponsor?
>> - Do folks generally think there's a chance of it being accepted without a
>> huge debate and expansion of
On Wed, 14 Apr 2021 at 18:01, David Mertz wrote:
>
> On Wed, Apr 14, 2021 at 5:44 PM Christopher Barker
> wrote:
>>
>> Another possible issue: using Version would require an extra import in many
>> module initializations -- is that a performance issue that would matter?
>
>
> I like having a
On Apr 13, 2021, at 22:40, Christopher Barker wrote:
>
> Turns out this was suggested in PEP 396 -- and deferred almost 13 years ago!
>
> https://www.python.org/dev/peps/pep-0396/
I’d forgotten that this PEP was in Deferred state. I think it should be
rejected and I plan on making that
On 4/14/2021 12:38 PM, Christopher Barker wrote:
Anyway, the question now for me is whether this is worth any more of
my time.
So:
- Is there someone willing to sponsor?
- Do folks generally think there's a chance of it being accepted
without a huge debate and expansion of scope.
I think
On Wed, Apr 14, 2021 at 5:44 PM Christopher Barker
wrote:
> Another possible issue: using Version would require an extra import in
> many module initializations -- is that a performance issue that would
> matter?
>
I like having a `Version` object that is easily importable in the standard
On Wed, Apr 14, 2021 at 5:24 AM Victor Stinner wrote:
> There are two main use cases for versions:
>
> * Display them to the user
> * Compare versions to check if one is newer, older or the same
>
> I dislike using strings for comparison. You need to use
> packaging.version for that:
>
Agreed!
I was trying to figure out why an API from Vaex 3.x was no longer working,
and to my human eye, this quickly pointed me at the issue. However as a
way to automatically check for versions, this is a mess. I have no idea
what additional keys the next version might add or remove, for
Simon,
I'm not sure your note made it to the list -- bringing it back on.
On Wed, Apr 14, 2021 at 1:15 AM Simon Cross
wrote:
> I would be +1 on having a small PEP like this one to give __version__
> an official blessing and some well-defined expected behaviour.
>
> I don't have a deep opinion
On Wed, Apr 14, 2021 at 7:48 AM David Mertz wrote:
> >>> vaex.__version__
> {'vaex': '4.1.0', 'vaex-core': '4.1.0', 'vaex-viz': '0.5.0', 'vaex-hdf5':
> '0.7.0', 'vaex-server': '0.4.0', 'vaex-astro': '0.8.0', 'vaex-jupyter':
> '0.6.0', 'vaex-ml': '0.11.1'}
>
Well, THAT is a great argument for
I recently encountered this, which is very useful, but only for a
human-readable perspective.
>>> import vaex
>>> vaex.__version__
{'vaex': '4.1.0', 'vaex-core': '4.1.0', 'vaex-viz': '0.5.0', 'vaex-hdf5':
'0.7.0', 'vaex-server': '0.4.0', 'vaex-astro': '0.8.0', 'vaex-jupyter':
'0.6.0', 'vaex-ml':
> In my Python projects, I like to provide the version as a tuple which
> can be used directly for comparison
To add to this, comparing tuples doesn't always work well for projects
where multiple release lines are maintained simultaneously, e.g.
user-facing changes introduced in minor/point
On Wed, 14 Apr 2021 at 13:28, Victor Stinner wrote:
> There are two main use cases for versions:
>
> * Display them to the user
> * Compare versions to check if one is newer, older or the same
>
> I dislike using strings for comparison. You need to use
> packaging.version for that:
>
On Wed, Apr 14, 2021 at 7:48 AM Christopher Barker wrote:
> So what do you'all think? After thirteen years, it would be nice to put this
> to bed.
There are two main use cases for versions:
* Display them to the user
* Compare versions to check if one is newer, older or the same
I dislike
49 matches
Mail list logo
