Hi Paul,
On Sun, May 1, 2022 at 3:47 PM Paul Bryan wrote:
>
> Can someone state what's currently unpalatable about 649? It seemed to
> address the forward-referencing issues, certainly all of the cases I was
> expecting to encounter.
Broadly speaking I think there are 3-4 issues to resolve as
On Tue, Apr 26, 2022 at 7:24 PM Greg Ewing
wrote:
> On 27/04/22 2:01 am, Chris Angelico wrote:
> > That would be the case if monkeypatching were illegal. Since it's not,
> > wherein lies the difference?
>
> The proposed feature is analogous to forward declaring a
> struct in C. Would you call
On Tue, Apr 26, 2022 at 1:25 PM Guido van Rossum wrote:
> I also would like to hear more about the problem this is trying to solve,
> when th real-world examples. (E.g. from pydantic?)
Yes please. I think these threads have jumped far too quickly into
esoteric details of implementation and
On Sun, Apr 24, 2022 at 10:20 AM Joao S. O. Bueno wrote:
>
> I am not worried about the bikeshed part of which syntax to use -
> and more worried with the possible breaking of a lot of stuff, unless
> we work with creation of a non-identical "forward object" that is
> rebound, as in plain name
Hi Larry,
On Sat, Apr 23, 2022 at 1:53 AM Larry Hastings wrote:
> But rather than speculate further, perhaps someone who works on one of the
> static type analysis checkers will join the discussion and render an informed
> opinion about how easy or hard it would be to support "forward class"
Hi Malthe,
On Fri, Apr 8, 2022 at 12:04 PM Malthe wrote:
> Actually, to me the interesting idea is not so much lazy imports – I
> think they should not be lazy, at least that was my initial thought. I
> think they should be immediately resolved before anything else in that
> module:
I'm +0.25
Hi Barry,
On Fri, Apr 8, 2022 at 12:44 PM Barry Warsaw wrote:
>
> Start up overhead due to imports is a real problem for some class of
> applications, e.g. CLIs, and I’ve seen a lot of hacks implemented to get
> Python CLIs to be more responsive. E.g. getting from invocation to —help
>
An interesting point in the lazy imports design space that I hadn't
previously considered could be:
- lazy imports are explicitly marked and usage of the imported name
within the module is transparent, but
- lazily imported names are _not_ visible in the module namespace;
they can't be accessed
You only get the ease-of-implementation benefit if you are willing to
explicitly mark every _use_ of a lazy-imported name as special (and
give the fully qualified name at every usage site). This is rather
more cumbersome (assuming multiple uses in a module) than just
explicitly marking an import
Hi Eric, just one note:
On Wed, Mar 9, 2022 at 7:13 PM Eric Snow wrote:
> > Maybe say “e.g. with Instagram's Cinder” – both the household name and
> > the project you can link to?
>
> +1
>
> Note that Instagram isn't exactly using Cinder.
This sounds like a misunderstanding somewhere. Instagram
On Thu, Dec 23, 2021 at 7:38 PM Barry Warsaw wrote:
>
> On Dec 23, 2021, at 17:09, Guido van Rossum wrote:
> >
> > Mark's proposal was
> > ```
> > @Callable
> > def func(params): pass
> > ```
> > My question is, why does it need `@Callable`? Lukasz proposed just using
> > any (undecorated)
On Thu, Oct 21, 2021 at 12:06 PM Jelle Zijlstra
wrote:
> I would want this for my type checker, pyanalyze. I'd want to get the raw
> annotation and turn it into a type. For example, if the annotation is
> `List[SomeType]` and `SomeType` is imported in `if TYPE_CHECKING`, I'd at
> least still
On Thu, Oct 21, 2021 at 10:44 AM Damian Shaw
wrote:
> Sorry for the naive question but why doesn't "TYPE_CHECKING" work under PEP
> 649?
>
> I think I've seen others mention this but as the code object isn't executed
> until inspected then if you are just using annotations for type hints it
>
On Mon, Aug 9, 2021 at 9:31 PM Inada Naoki wrote:
> Currently, reference implementation of PEP 649 has been suspended.
> We need to revive it and measure performance/memory impact.
I volunteered to check performance impact in practice on the Instagram
codebase, which is almost fully annotated.
On Sun, Apr 25, 2021 at 10:30 AM Brett Cannon wrote:
> I know I would be curious, especially if backwards compatibility can be
> solved reasonably (for those that haven't lived this, deferred execution
> historically messes up code relying on import side-effects and trackbacks are
> weird as
Hi Larry,
This is a creative option, but I am optimistic (now that the SC
decision has removed the 3.10 deadline urgency) that we can find a
path forward that is workable for everyone and doesn't require a
permanent compiler feature flag and a language that is permanently
split-brained about
Hi Barry & Luciano,
Barry Warsaw wrote:
> Actually, I think it’s time for a comprehensive guide to type annotations.
> Just anecdotally, I was trying to annotate a library of mine and was having
> an impossible time of it, until a chat with Guido lead me to
> @typing.overload. That solved my
Hi Larry,
On 4/14/21, 1:56 PM, "Larry Hastings" wrote:
>My plan was to post it here and see what the response was first. Back in
> January, when I posted the first draft, I got some very useful feedback that
> resulted in some dramatic changes. This time around, so far, nobody has
>
Hi Larry,
On 4/12/21, 6:57 PM, "Larry Hastings" wrote:
Again, by "works on PEP 563 semantics", you mean "doesn't raise an error".
But the code has an error. It's just that it has been hidden by PEP 563
semantics.
I don't agree that changing Python to automatically hide errors is an
On Thu, Apr 30, 2020 at 3:12 PM Raymond Hettinger
wrote:
> Thanks for the concrete example. AFAICT, it doesn't require (and probably
> shouldn't have) a lock to be held for the duration of the call. Would it be
> fair to say the 100% of your needs would be met if we just added this to the
>
On Wed, Apr 29, 2020 at 9:36 PM Raymond Hettinger
wrote:
> Do you have some concrete examples we could look at? I'm having trouble
> visualizing any real use cases and none have been presented so far.
This pattern occurs not infrequently in our Django server codebase at
Instagram. A typical
On Sat, Apr 18, 2020 at 10:38 PM Guido van Rossum wrote:
>
> Note that, while there is indeed a docs page about 2to3, the only docs for
> lib2to3 in the standard library reference are a link to the source code and a
> single "Note: The lib2to3 API should be considered unstable and may change
>
The PEP is exciting and is very clearly presented, thank you all for
the hard work!
Considering the comments in the PEP about the new parser not
preserving a parse tree or CST, I have some questions about the future
options for Python language-services tooling which requires a CST in
order to
On 11/29/2017 05:02 PM, Guido van Rossum wrote:
> I tried to look up the discussion but didn't find much except that you
> flagged this as an issue. To repeat, your concern is that isdataclass()
> applies to *instances*, not classes, which is how Eric has designed it,
> but you worry that either
On 11/29/2017 03:26 PM, Eric V. Smith wrote:
> I've posted a new version of PEP 557, it should soon be available at
> https://www.python.org/dev/peps/pep-0557/.
>
> The only significant changes since the last version are:
>
> - changing the "compare" parameter to be "order", since that more
>
Hi Eric,
Really excited about this PEP, thanks for working on it. A couple minor
questions:
> If compare is True, then eq is ignored, and __eq__ and __ne__ will be
automatically generated.
IMO it's generally preferable to make nonsensical parameter combinations
an immediate error, rather than
On 05/09/2017 10:28 AM, Guido van Rossum wrote:
> There's a proposal to change one detail of PEP 484. It currently says:
>
> An optional type is also automatically assumed when the default value is
> |None|, for example::
>
> |def handle_employee(e: Employee = None): ... |
>
>
On 08/10/2015 02:49 PM, Eric V. Smith wrote:
On 08/10/2015 02:44 PM, Yury Selivanov wrote:
On 2015-08-10 2:37 PM, Eric V. Smith wrote:
Besides, any expression you have to calculate can go in a local that
will get
interpolated. The same goes for any !r or other formatting
modifiers. In an
On 07/30/2015 09:03 PM, Nikolaus Rath wrote:
Nick recently mentioned that the PSF might be able to help, but that the
initiative for that needs to come from the core developers. So why don't
you guys ask the PSF to e.g. sponsor some of the work that no one feels
motivated to do in their spare
On 05/28/2015 11:52 AM, Paul Moore wrote:
[snip]
Nevertheless, I would like to understand how Unix can manage to have a
Python 3.4.3 binary at 4kb. Does that *really* have no external
dependencies (other than the C library)? Are we really comparing like
with like here?
I don't know what
Hi Lennart,
On 04/08/2015 09:18 AM, Lennart Regebro wrote:
I wrote PEP-431 two years ago, and never got around to implement it.
This year I got some renewed motivation after Berker Peksağ made an
effort of implementing it.
I'm planning to work more on this during the PyCon sprints, and also
On 04/25/2014 01:55 PM, Ethan Furman wrote:
On 04/25/2014 12:45 PM, Florent wrote:
2014-04-25 18:10 GMT+02:00 Nick Coghlan:
And if you're going to publish a tool to enforce your *personal* style
guide and include your own custom rules that the this is OK examples
in PEP 8 fail to satisfy,
Hi Ethan,
I haven't chimed into this discussion, but the direction it's headed
recently seems right to me. Thanks for putting together a PEP. Some
comments on it:
On 01/15/2014 05:13 PM, Ethan Furman wrote:
Abstract
This PEP proposes adding the % and
On 02/20/2013 01:53 PM, Skip Montanaro wrote:
That's not very good. XML parsers are supposed to parse XML according
to standards. Is the goal to have them actually do that, or just
address DDOS issues?
Having read through Christian's mail and several of his references, it
seems to me that
On 02/20/2013 03:35 PM, Greg Ewing wrote:
Carl Meyer wrote:
An XML parser that follows the XML standard is never safe to expose to
untrusted input.
Does the XML standard really mandate that a conforming parser
must blindly download any DTD URL given to it from the real
live internet
Hi Stefan,
On 07/19/2012 06:28 AM, Stefan H. Holek wrote:
While trying 3.3 beta I found that I cannot use my favorite
virtualenv pattern with pyvenv:
$ virtualenv . Installing.done.
$ pyvenv . Error: Directory exists: /Users/stefan/sandbox/foo
I appreciate that this behavior is
On 07/19/2012 10:26 AM, Andrew Svetlov wrote:
virtualenv has virtualenv.csh and virtualenv.fish files.
Is there any reason for restricting venv to bash/zsh only?
No. As far as I'm concerned, a patch to port the virtualenv csh and fish
activate scripts to pyvenv would be welcome (though I can't
Hi Paul,
On 06/20/2012 09:29 AM, Paul Moore wrote:
As a specific example, one thing I would like to do is to be able to
set up a packaging.pypi client object that lets me query and download
distributions. However, rather than just querying PyPI (the default)
I'd like to be able to set up a
Hi Alexis,
On 06/20/2012 10:57 AM, Alexis Métaireau wrote:
Le mer. 20 juin 2012 18:45:23 CEST, Paul Moore a écrit :
Thanks - as you say, it's not so much the actual problem as the
principle of what the packaging API offers that matters here. Although
it does make a good point - to what extent
Hello Christian,
On 06/03/2012 03:56 PM, Éric Araujo wrote:
Le 02/06/2012 12:59, Christian Tismer a écrit :
One urgent question: will this feature be backported to Python 2.7?
Features are never backported to the stable versions. virtualenv still
exists as a standalone project which is
On 05/28/2012 04:24 PM, Nick Coghlan wrote:
It would have been better if the issue of script management on Windows
had been raised in PEP 405 itself - I likely would have declared PEP
397 a dependency *before* accepting it (even if that meant the feature
missed the alpha 4 deadline and first
Hi Paul,
On 05/07/2012 04:16 PM, Paul Moore wrote:
On 7 May 2012 21:55, Martin v. Löwismar...@v.loewis.de wrote:
This sounds to me like a level of complexity unwarranted by the severity
of the problem, especially when considering the additional burden it
imposes on alternative Python
On 05/07/2012 04:26 AM, Ronald Oussoren wrote:
On 7 May, 2012, at 11:52, Martin v. Löwis wrote:
3) Symlink the interpreter rather than copying. I include this
here for the sake of completeness, but it's already been rejected
due to significant problems on older Windows' and OS X.
That sounds
On 05/07/2012 03:52 AM, Martin v. Löwis wrote:
3) Symlink the interpreter rather than copying. I include this here for
the sake of completeness, but it's already been rejected due to
significant problems on older Windows' and OS X.
That sounds the right solution to me. PEP 405 specifies that
On 05/05/2012 02:38 AM, Vinay Sajip wrote:
Nick Coghlanncoghlanat gmail.com writes:
Personally, I expect that always update your virtual environment
binaries after updating the system Python to a new point release will
itself become a recommended practice when using virtual environments.
On 05/05/2012 04:40 AM, Antoine Pitrou wrote:
On Fri, 04 May 2012 14:49:03 -0600
Carl Meyerc...@oddbird.net wrote:
3) Symlink the interpreter rather than copying. I include this here for
the sake of completeness, but it's already been rejected due to
significant problems on older Windows' and
On 05/05/2012 12:41 AM, Nick Coghlan wrote:
On Sat, May 5, 2012 at 6:49 AM, Carl Meyerc...@oddbird.net wrote:
1) Document it and provide a tool for easily upgrading a venv in this
situation. This may be adequate. In practice the situation is quite rare:
2.6.8/2.7.3 is the only actual example
Hi all,
The recent virtualenv breakage in Python 2.6.8 and 2.7.3 reveals an
issue that deserves to be explicitly addressed in PEP 405: what happens
when the system Python underlying a venv gets an in-place bugfix
upgrade. If the bugfix includes a simultaneous change to the interpreter
and
Hi all,
Are the download pages for older Python versions supposed to be kept up
to date at all? I just noticed that the 2.4.6 download page
(http://www.python.org/download/releases/2.4.6/) says things like
Python 2.4 is now in security-fix-only mode (whereas in fact it no
longer gets even
On 04/27/2012 08:36 AM, Guido van Rossum wrote:
Someone should contact the Django folks. Alex Gaynor?
I committed the relevant code to Django (though I didn't write the
patch), and I've been following this thread. I have it on my todo list
to review this code again with Ezio's suggestions in
Thanks Jason for raising this. I just assumed that this was virtualenv's
fault (which it is) and didn't consider raising it here, but a note in
the release notes for the affected Python versions will certainly reach
many more of the likely-to-be-affected users.
FTR, I confirmed that the issue
On 03/29/2012 11:39 AM, David Malcolm wrote:
jaraco@vdm-dev:~$ env/bin/python -c import os; os.urandom()
Traceback (most recent call last):
File string, line 1, in module
AttributeError: 'module' object has no attribute 'urandom'
It looks like this a symptom of the move of urandom to
Hi Jason,
On 03/28/2012 12:22 PM, Jason R. Coombs wrote:
To reproduce, using virtualenv 1.7+ on Python 2.7.2 on Ubuntu, create a
virtualenv. Move that virtualenv to a host with Python 2.7.3RC2 yields:
jaraco@vdm-dev:~$ /usr/bin/python2.7 -V
Python 2.7.3rc2
jaraco@vdm-dev:~$
On 03/23/2012 09:22 PM, PJ Eby wrote:
On Mar 23, 2012 3:53 PM, Carl Meyer c...@oddbird.net
On 03/23/2012 12:35 PM, PJ Eby wrote:
AFAICT, virtualenvs are overkill for most development anyway. If you're
not using distutils except to install dependencies, then configure
distutils to install
On 03/20/2012 12:19 PM, Paul Moore wrote:
I also note that I'm assuming virtualenv will change to match whatever
the Python version it's referencing does. I don't see how you can
guarantee that, but if there are discrepancies between virtualenvs and
installed Pythons, my level of objection
Hello Kristján,
On 03/19/2012 03:26 AM, Kristján Valur Jónsson wrote:
Hi Carl. I'm very interested in this work. At CCP we work heavily
with virtual environments. Except that we don't use virtualenv
because it is just a pain in the neck. We like to be able to run
virtual python environments
Hi Van,
On 03/16/2012 08:08 AM, Lindberg, Van wrote:
Changing the directory name is in fact a new and different (and much
more invasive) special case, because distutils et al install scripts
there, and that directory name is part of the distutils install scheme.
Installers don't care where
Hi Mark,
On 03/16/2012 05:53 PM, Mark Hammond wrote:
* All executables and scripts go into the root of the Python install.
This directory is largely empty now - it is mainly a container for other
directories. This would solve the problem of needing 2 directories on
the PATH and mean existing
A brief status update on PEP 405 (built-in virtualenv) and the open issues:
1. As mentioned in the updated version of the language summit notes,
Nick Coghlan has agreed to pronounce on the PEP.
2. Ned Deily discovered at the PyCon sprints that the current reference
implementation does not work
On 03/15/2012 03:02 PM, Lindberg, Van wrote:
FYI, the location of the tcl/tk libraries does not appear to be set in
the virtualenv, even if tkinter is installed and working in the main
Python installation. As a result, tk-based apps will not run from a
virtualenv.
Thanks for the report!
On 03/15/2012 04:19 PM, Mark Hammond wrote:
On 16/03/2012 8:57 AM, VanL wrote:
On 3/14/2012 6:30 PM, Mark Hammond wrote:
So why not just standardize on that new layout for virtualenvs?
That sounds like the worst of all worlds - keep all the existing special
cases, and add one.
I'm not so
On 03/15/2012 05:10 PM, Mark Hammond wrote:
On 16/03/2012 10:48 AM, Carl Meyer wrote:
The implementation of virtualenv (and especially PEP 405 pyvenv) are
largely based around making sure that the internal layout of a
virtualenv is identical to the layout of an installed Python on that
same
-BEGIN PGP SIGNED MESSAGE-
Hash: SHA1
Hi Victor,
On 01/19/2012 05:48 PM, Victor Stinner wrote:
[snip]
Using a randomized hash may
also break (indirectly) real applications because the application
output is also somehow randomized. For example, in the Django test
suite, the HTML
On 12/09/2011 08:35 AM, Michael Foord wrote:
On 9 Dec 2011, at 15:13, Barry Warsaw wrote:
Oh, I remember this one, because I think I reported and fixed it.
But I take it as a given that Python 2.6 is the minimal (sane)
version to target for one-codebase cross-Python code.
In mock (at
-BEGIN PGP SIGNED MESSAGE-
Hash: SHA1
On 12/09/2011 07:45 AM, Lennart Regebro wrote:
The slowness of running 2to3 during install time can be fixed by not
doing so, but instead running it when the distribution is created,
including both Python 2 and Python 3 code in the distribution.
-BEGIN PGP SIGNED MESSAGE-
Hash: SHA1
On 11/10/2011 07:17 AM, Vinay Sajip wrote:
Barry Warsaw barry at python.org writes:
On Nov 10, 2011, at 08:58 AM, Nick Coghlan wrote:
Now you need to persuade Vinay to let you trade PEP numbers with the
pyvenv PEP. Having an unrelease schedule
-BEGIN PGP SIGNED MESSAGE-
Hash: SHA1
On 11/08/2011 05:43 PM, Nick Coghlan wrote:
I'm actually finding I quite like the virtualenv scheme of having
sys.prefix refer to the virtual environment and sys.real_prefix
refer to the interpeter's default environment. If pyvenv used the same
-BEGIN PGP SIGNED MESSAGE-
Hash: SHA1
On 10/31/2011 09:57 PM, Stephen J. Turnbull wrote:
That's fine, but either make sure it works with a POSIX-conformant
/bin/sh, or make the shebang explicitly bash (bash is notoriously
buggy in respect of being POSIX-compatible when named sh).
It
-BEGIN PGP SIGNED MESSAGE-
Hash: SHA1
On 10/28/2011 05:10 PM, Chris McDonough wrote:
Why not modify sys.prefix?
- --
As discussed above under `Backwards Compatibility`_, this PEP proposes
to add ``sys.site_prefix`` as the prefix relative to which
site-package
-BEGIN PGP SIGNED MESSAGE-
Hash: SHA1
On 10/30/2011 04:47 PM, Vinay Sajip wrote:
Antoine Pitrou solipsis at pitrou.net writes:
It would be even simpler not to process it at all, but install the
scripts as-is (without the execute bit) :)
Sure, but such an approach makes it difficult to
-BEGIN PGP SIGNED MESSAGE-
Hash: SHA1
On 10/31/2011 09:35 AM, Vinay Sajip wrote:
That's true, I hadn't thought of that. So then it sounds like the thing to do
is
make venv a package and have the code in venv/__init__.py, then have the
scripts
in a 'scripts' subdirectory below that.
-BEGIN PGP SIGNED MESSAGE-
Hash: SHA1
On 10/30/2011 06:28 AM, Antoine Pitrou wrote:
On Sun, 30 Oct 2011 12:10:18 + (UTC)
Vinay Sajip vinay_sa...@yahoo.co.uk wrote:
We already have Unix shell scripts and BAT files in the source tree. Is
it really complicated to maintain these
-BEGIN PGP SIGNED MESSAGE-
Hash: SHA1
On 10/31/2011 10:28 AM, Paul Moore wrote:
On 31 October 2011 16:08, Tres Seaver tsea...@palladion.com wrote:
On 10/31/2011 11:50 AM, Carl Meyer wrote:
I have no problem including the basic posix/nt activate scripts if
no one else is concerned
: XXX
Title: Python Virtual Environments
Version: $Revision$
Last-Modified: $Date$
Author: Carl Meyer c...@oddbird.net
Status: Draft
Type: Standards Track
Content-Type: text/x-rst
Created: 13-Jun-2011
Python-Version: 3.3
Post-History: 24-Oct-2011, 28-Oct-2011
Abstract
This PEP proposes
-BEGIN PGP SIGNED MESSAGE-
Hash: SHA1
Hi Éric,
Vinay is more up to date than I am on the current status of the
implementation. I need to update the PEP draft we worked on last spring
and get it posted (the WIP is at
https://bitbucket.org/carljm/pythonv-pep but is out of date with the
-BEGIN PGP SIGNED MESSAGE-
Hash: SHA1
On 10/06/2011 12:12 PM, Nick Coghlan wrote:
sandbox is a bit close to Victor's pysandbox for restricted execution
environments.
'nest' would probably work, although I don't recall the 'egg'
nomenclature featuring heavily in the current zipimport
On 06/13/2011 06:55 AM, Michael Foord wrote:
There are two options:
Bring the full functionality into the standard library so that Python
supports virtual environments out of the box. As is the case with adding
anything to the standard library it will then be impossible to add
features to
On 06/13/2011 08:07 AM, Nick Coghlan wrote:
On Mon, Jun 13, 2011 at 10:50 PM, Vinay Sajip vinay_sa...@yahoo.co.uk wrote:
You're right in terms of the current Python ecosystem and 3.x adoption,
because
of course this approach requires support from Python itself in terms of its
site.py code.
On 06/13/2011 06:46 PM, Carl Meyer wrote:
FWIW, historically pretty much every new Python version has broken
virtualenv
I should clarify that this is because of the delicate stdlib
bootstrapping virtualenv currently has to do; the built-in virtualenv
eliminates this entirely and will require
On 05/29/2011 06:11 PM, Jack Diederich wrote:
We don't, but many projects do
release new features with bugfix version numbers - I'm looking at you,
Django.
Really? Do you have an example of a new Django feature that was released
in a bugfix version number? Just curious, since that's
On 04/15/2011 08:53 AM, Michael Foord wrote:
If we treat django's failure to use super as a bug, you want the
Python language to work-around that bug so that:
What you say (that this particular circumstance could be treated as a
bug in django) is true,
Just as a side note: if there is a
-BEGIN PGP SIGNED MESSAGE-
Hash: SHA1
Hi Senthil,
On 03/21/2011 09:57 PM, Senthil Kumaran wrote:
- In the above issue, why is two same bitbutket urls are provided. (It
is redundant).
I updated the patch, and the second time around the remote hg repo box
was empty. I wasn't sure what
82 matches
Mail list logo
