Re: [Python-Dev] Feature request: Change a Dependency Package Version During Package Initiation

2019-05-17 Thread Q via Python-Dev
Sorry, there is an error in my last post. It's corrected as:

The abaqus python distribution has libA 1.0, the external package to be 
installed is LibB, which requires libA2.0, and we don't want to change every 
import in LibB to be import /somewhere/libA2.0, because the source code may 
have not been provided.





 在 星期六, 2019-05-18 10:26:04 Q  撰写 



>From the viewpoint of the package user, people don't want to change every 
>import to "require a version at runtime". If "set up a python path in a 
>wrapper script" is a better strategy, can you please give an example for the 
>following use case:


The abaqus python distribution has libA 1.0, the external package to be 
installed is LibB, which requires libA2.0, and we don't want to change every 
import in LibB to be import libA 1.0, because the source code may have not been 
provided.

In emacs, you can always advice a command to change its behaviour, which makes 
it very user friendly, and that what all the following suggestion is about. I 
have no idea at all how it could be implemented though.

https://github.com/mitsuhiko/multiversion/issues/1

"The work around is to let a version to be set within a package and have that 
propagate to all modules in that package. For example in the root init.py if I 
set tonado version to be 2.2.1 then all modules in that package will use 
tornado 2.2.1 when I import tornado."



 在 星期五, 2019-05-17 23:38:55 Daniel Holth  撰写 










This sounds exactly like what people used to do with eggs. You could have 
multiple versions of a package on the path as eggs and then require a version 
at runtime. The approach has problems. Ruby also abandoned a strategy where 
random app code depends on package management code at runtime.



One better strategy is to set up a python path in a wrapper script.




On Fri, May 17, 2019, 11:27 Brett Cannon  wrote:





Thanks for the idea but there are currently no plans to support such a feature. 
If you would like to see it then you will need to write a PEP with a 
proof-of-concept to demonstrate how you would expect such a feature to work.



On Fri., May 17, 2019, 07:55 Q via Python-Dev,  
wrote:



A lot of the Python code we use in production are used directly as imports in 
other python

distributions (such as the python comes with the finite element software Abaqus 
and MSC Marc), many

packages (such as matplotlib, numpy) that may have varying versioned 
dependencies.



I was wondering if this could be expanded to allow a version to be set within a 
package and have

that propagate to all modules in that package. For example in the root init.py 
if I set

multiversion(tornado, 2.2.1) then all modules in that package will use tornado 
2.2.1 when I import

tornado.



See a relevant issue on github:

https://github.com/mitsuhiko/multiversion/issues/1



Thank you!

Qiang





___

Python-Dev mailing list

mailto: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

mailto:Python-Dev@python.org

https://mail.python.org/mailman/listinfo/python-dev

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


Re: [Python-Dev] Feature request: Change a Dependency Package Version During Package Initiation

2019-05-17 Thread Q via Python-Dev
>From the viewpoint of the package user, people don't want to change every 
>import to "require a version at runtime". If "set up a python path in a 
>wrapper script" is a better strategy, can you please give an example for the 
>following use case:


The abaqus python distribution has libA 1.0, the external package to be 
installed is LibB, which requires libA2.0, and we don't want to change every 
import in LibB to be import libA 1.0, because the source code may have not been 
provided.

In emacs, you can always advice a command to change its behaviour, which makes 
it very user friendly, and that what all the following suggestion is about. I 
have no idea at all how it could be implemented though.

https://github.com/mitsuhiko/multiversion/issues/1

"The work around is to let a version to be set within a package and have that 
propagate to all modules in that package. For example in the root init.py if I 
set tonado version to be 2.2.1 then all modules in that package will use 
tornado 2.2.1 when I import tornado."



 在 星期五, 2019-05-17 23:38:55 Daniel Holth  撰写 



This sounds exactly like what people used to do with eggs. You could have 
multiple versions of a package on the path as eggs and then require a version 
at runtime. The approach has problems. Ruby also abandoned a strategy where 
random app code depends on package management code at runtime.



One better strategy is to set up a python path in a wrapper script.




On Fri, May 17, 2019, 11:27 Brett Cannon  wrote:





Thanks for the idea but there are currently no plans to support such a feature. 
If you would like to see it then you will need to write a PEP with a 
proof-of-concept to demonstrate how you would expect such a feature to work.



On Fri., May 17, 2019, 07:55 Q via Python-Dev,  
wrote:



A lot of the Python code we use in production are used directly as imports in 
other python

distributions (such as the python comes with the finite element software Abaqus 
and MSC Marc), many

packages (such as matplotlib, numpy) that may have varying versioned 
dependencies.



I was wondering if this could be expanded to allow a version to be set within a 
package and have

that propagate to all modules in that package. For example in the root init.py 
if I set

multiversion(tornado, 2.2.1) then all modules in that package will use tornado 
2.2.1 when I import

tornado.



See a relevant issue on github:

https://github.com/mitsuhiko/multiversion/issues/1



Thank you!

Qiang





___

 Python-Dev mailing list

 mailto: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

 mailto:Python-Dev@python.org

 https://mail.python.org/mailman/listinfo/python-dev

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


[Python-Dev] Summary of Python tracker Issues

2019-05-17 Thread Python tracker

ACTIVITY SUMMARY (2019-05-10 - 2019-05-17)
Python tracker at https://bugs.python.org/

To view or respond to any of the issues listed below, click on the issue.
Do NOT respond to this message.

Issues counts and deltas:
  open7067 (-17)
  closed 41633 (+91)
  total  48700 (+74)

Open issues with patches: 2861 


Issues opened (56)
==

#36084: Threading: add builtin TID attribute to Thread objects
https://bugs.python.org/issue36084  reopened by vstinner

#36801: Wait for connection_lost in StreamWriter.drain
https://bugs.python.org/issue36801  reopened by asvetlov

#36802: Revert back StreamWriter awrite/aclose but provide await write
https://bugs.python.org/issue36802  reopened by vstinner

#36817: Add = to f-strings for easier debugging.
https://bugs.python.org/issue36817  reopened by pablogsal

#36876: Global C variables are a problem.
https://bugs.python.org/issue36876  opened by eric.snow

#36877: [meta] Move fields from _PyRuntimeState to PyInterpreterState.
https://bugs.python.org/issue36877  opened by eric.snow

#36878: ast.parse with type_comments=True should allow extra text afte
https://bugs.python.org/issue36878  opened by msullivan

#36879: bug with round() and "numpy floats"
https://bugs.python.org/issue36879  opened by Scaler

#36880: Returning None from a callback with restype py_object decremen
https://bugs.python.org/issue36880  opened by dgelessus

#36881: isinstance raises TypeError for metaclass with metaclass=ABCMe
https://bugs.python.org/issue36881  opened by emanspeaks

#36882: 在ctypes里调用C库返回c_char_p类型时的问题
https://bugs.python.org/issue36882  opened by fy2099

#36885: Make makeunicode.py script more readable
https://bugs.python.org/issue36885  opened by scoder

#36887: Add integer square root, math.isqrt
https://bugs.python.org/issue36887  opened by mark.dickinson

#36888: Create a way to check that the parent process is alive for dea
https://bugs.python.org/issue36888  opened by tomMoral

#36889: Merge StreamWriter and StreamReader into just asyncio.Stream
https://bugs.python.org/issue36889  opened by asvetlov

#36890: python-3.7.3-macosx10.6.pkg verification error on macOS 10.6 S
https://bugs.python.org/issue36890  opened by steve_314

#36891: Additional startup plugin for vendors
https://bugs.python.org/issue36891  opened by vx1920

#36892: "Modules" section in Tutorial contains incorrect description a
https://bugs.python.org/issue36892  opened by musou1500

#36893: email.headerregistry.Address blocks Unicode local part addr_sp
https://bugs.python.org/issue36893  opened by dracos

#36894: test_multiprocessing_spawn regression on Windows
https://bugs.python.org/issue36894  opened by pitrou

#36895: time.clock() marked for removal in 3.8 – still there.
https://bugs.python.org/issue36895  opened by mbussonn

#36896: clarify in types.rst that FunctionTypes & co  constructors don
https://bugs.python.org/issue36896  opened by mbussonn

#36897: shlex doesn't differentiate escaped characters in output
https://bugs.python.org/issue36897  opened by Matthew Gamble

#36898: Add parameter @case_sensitive to glob and rglob in pathlib
https://bugs.python.org/issue36898  opened by Chuang Men

#36901: Fix leaks in /PC/bdist_wininst/install.c
https://bugs.python.org/issue36901  opened by cheryl.sabella

#36904: Implement _PyStack_UnpackDict() with a single allocation
https://bugs.python.org/issue36904  opened by jdemeyer

#36905: test_typing.GetTypeHintTests.test_get_type_hints_modules_forwa
https://bugs.python.org/issue36905  opened by xtreak

#36906: Compile time textwrap.dedent() equivalent for str or bytes lit
https://bugs.python.org/issue36906  opened by gregory.p.smith

#36907: Crash due to borrowed references in _PyStack_UnpackDict()
https://bugs.python.org/issue36907  opened by jdemeyer

#36908: "This module is always available" is confusing
https://bugs.python.org/issue36908  opened by nedbat

#36910: Certain Malformed email causes email.parser to throw Attribute
https://bugs.python.org/issue36910  opened by msapiro

#36913: Missing documentation for decorators
https://bugs.python.org/issue36913  opened by tomerv

#36917: ast.NodeVisitor no longer calls visit_Str
https://bugs.python.org/issue36917  opened by Anthony Sottile

#36918: ValueError warning in test_urllib due to io.IOBase destructor
https://bugs.python.org/issue36918  opened by xtreak

#36919: Exception from 'compile' reports a newline char not present in
https://bugs.python.org/issue36919  opened by BCSharp

#36921: Deprecate yield from and @coroutine in asyncio
https://bugs.python.org/issue36921  opened by asvetlov

#36922: Implement Py_TPFLAGS_METHOD_DESCRIPTOR
https://bugs.python.org/issue36922  opened by jdemeyer

#36924: Simplify implementation of classmethod_descriptor.__call__
https://bugs.python.org/issue36924  opened by jdemeyer

#36926: Implement methoddescr_call without _PyMethodDef_RawFastCallDic
https://bugs.python.org/issue36926  opened by jdemeyer

#36927: 

Re: [Python-Dev] Feature request: Change a Dependency Package Version During Package Initiation

2019-05-17 Thread Daniel Holth
This sounds exactly like what people used to do with eggs. You could have
multiple versions of a package on the path as eggs and then require a
version at runtime. The approach has problems. Ruby also abandoned a
strategy where random app code depends on package management code at
runtime.

One better strategy is to set up a python path in a wrapper script.

On Fri, May 17, 2019, 11:27 Brett Cannon  wrote:

> Thanks for the idea but there are currently no plans to support such a
> feature. If you would like to see it then you will need to write a PEP with
> a proof-of-concept to demonstrate how you would expect such a feature to
> work.
>
> On Fri., May 17, 2019, 07:55 Q via Python-Dev, 
> wrote:
>
>> A lot of the Python code we use in production are used directly as
>> imports in other python
>> distributions (such as the python comes with the finite element software
>> Abaqus and MSC Marc), many
>> packages (such as matplotlib, numpy) that may have varying versioned
>> dependencies.
>>
>> I was wondering if this could be expanded to allow a version to be set
>> within a package and have
>> that propagate to all modules in that package. For example in the root
>> init.py if I set
>> multiversion(tornado, 2.2.1) then all modules in that package will use
>> tornado 2.2.1 when I import
>> tornado.
>>
>> See a relevant issue on github:
>> https://github.com/mitsuhiko/multiversion/issues/1
>>
>> Thank you!
>> Qiang
>>
>> ___
>> 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/dholth%40gmail.com
>
___
Python-Dev mailing list
Python-Dev@python.org
https://mail.python.org/mailman/listinfo/python-dev
Unsubscribe: 
https://mail.python.org/mailman/options/python-dev/archive%40mail-archive.com


Re: [Python-Dev] Feature request: Change a Dependency Package Version During Package Initiation

2019-05-17 Thread Brett Cannon
Thanks for the idea but there are currently no plans to support such a
feature. If you would like to see it then you will need to write a PEP with
a proof-of-concept to demonstrate how you would expect such a feature to
work.

On Fri., May 17, 2019, 07:55 Q via Python-Dev, 
wrote:

> A lot of the Python code we use in production are used directly as imports
> in other python
> distributions (such as the python comes with the finite element software
> Abaqus and MSC Marc), many
> packages (such as matplotlib, numpy) that may have varying versioned
> dependencies.
>
> I was wondering if this could be expanded to allow a version to be set
> within a package and have
> that propagate to all modules in that package. For example in the root
> init.py if I set
> multiversion(tornado, 2.2.1) then all modules in that package will use
> tornado 2.2.1 when I import
> tornado.
>
> See a relevant issue on github:
> https://github.com/mitsuhiko/multiversion/issues/1
>
> Thank you!
> Qiang
>
> ___
> 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] Feature request: Change a Dependency Package Version During Package Initiation

2019-05-17 Thread Q via Python-Dev
A lot of the Python code we use in production are used directly as imports in 
other python

distributions (such as the python comes with the finite element software Abaqus 
and MSC Marc), many

packages (such as matplotlib, numpy) that may have varying versioned 
dependencies.



I was wondering if this could be expanded to allow a version to be set within a 
package and have

that propagate to all modules in that package. For example in the root init.py 
if I set

multiversion(tornado, 2.2.1) then all modules in that package will use tornado 
2.2.1 when I import

tornado.



See a relevant issue on github:

https://github.com/mitsuhiko/multiversion/issues/1



Thank you!

Qiang___
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] Feature request: Change a Dependency Package Version During Package Initiation

2019-05-17 Thread Q via Python-Dev
A lot of the Python code we use in production are used directly as imports in 
other python



distributions (such as the python comes with the finite element software Abaqus 
and MSC Marc), many

packages (such as matplotlib, numpy) that may have varying versioned 
dependencies, which makes it is

a pain to get all these dependencies met in those close source python 
distributions.



The work around is to let a version to be set within a package and have that 
propagate to all

modules in that package. For example in the root init.py if I set tonado 
version to be 2.2.1 then

all modules in that package will use tornado 2.2.1 when I import tornado.



See a relevant issue of a similar package on github:

https://github.com/mitsuhiko/multiversion/issues/1



Thank you!

Qiang___
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] Consolidating channel of record [was: 581 (Using GitHub issues for CPython) is accepted]

2019-05-17 Thread Stephen J. Turnbull
Chris Barker - NOAA Federal writes:

 > Frankly, multiple long meandering threads in s single mailing list
 > are not s very good archive either.

True, but I have no idea how to address that administratively, except
to have a *very* strong moderator.

 > Ideally, the PEP is updated with a summary of the issues discussed
 > as the discussion unfolds.

The point of "channel of record" is not that it would replace the PEPs
themselves.  It's that PEP authors are people with time limitations,
too.

For example, there's at least one person currently requesting a review
on a PEP who has in the past loudly and publicly announced their
unsubscription from python-ideas and IIRC even python-dev.  I think
it's a good idea to have *one* place that is the principal source for
PEP protagonists who don't have time for or simply dislike
participating in some (or even all) of the channels du jour.  With a
designated channel of record, if discussions take place elsewhere, the
PEP protagonist *may*, but would be under *no obligation* to, follow
them or search for them.  In the current situation, there's an
implicit obligation for the protagonist to check all the channels,
maybe even to do a Google search.  Or at least some of the posters
seem to feel that way.

 > As the community seems to be moving to a wider variety of fora,
 > this will become all the more critical.

It would also be possible, I suppose, for the PEP protagonist to
designate a channel in the PEP.  That has its problems too (they can
choose a channel that is inconvenient for the majority of interested
participants, for example), but with a designated channel system of
either kind the problems are predictable and bounded.

Steve
___
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