Big +1. I love the idea.
str (especially, docstring), dict, and tuples are major memory eater in Python.
This may reduce tuple memory usage massively.
INADA Naoki
On Fri, Sep 8, 2017 at 2:30 AM, Neil Schemenauer wrote:
> Python objects that participate in cyclic GC (things like lists, dicts
No worries. We all learned stuff!
On Wed, Sep 6, 2017 at 4:22 PM, R. David Murray
wrote:
> On Wed, 06 Sep 2017 09:43:53 -0700, Guido van Rossum
> wrote:
> > I'm actually not in favor of this. It's another way to do the same thing.
> > Sorry to rain on your dream!
>
> So it goes :) I learned th
Fixed. Thanks to infra team.
http://psf.upfronthosting.co.za/roundup/meta/issue638
INADA Naoki
On Fri, Sep 1, 2017 at 9:57 PM, Victor Stinner wrote:
> Hi,
>
> When I go to http://bugs.python.org/ Firefox warns me that the form on
> the left to login (user, password) sends data in clear text
Would that not be a security concern, if you can get Python to execute
arbitrary code just by setting an environment variable?
On Thu, Sep 7, 2017 at 10:47 PM, Barry Warsaw wrote:
> On Sep 7, 2017, at 19:34, Nick Coghlan wrote:
>
> > Now that you put it that way, it occurs to me that CI environ
On Sep 7, 2017, at 19:34, Nick Coghlan wrote:
> Now that you put it that way, it occurs to me that CI environments
> could set "PYTHONBREAKPOINTHOOK=sys:exit" to make breakpoint() an
> immediate failure rather than halting the CI run waiting for input
> that will never arrive.
You better watch o
On Sep 7, 2017, at 18:03, Fernando Perez wrote:
> Ah, perfect! I've subscribed to the PR on github and can pitch in there
> further if my input is of any use.
Awesome, thanks!
-Barry
signature.asc
Description: Message signed with OpenPGP
___
Python
On Sep 7, 2017, at 16:19, Terry Reedy wrote:
> I think breakpoint() should have a db= parameter so one can select a debugger
> in one removable line. The sys interface is more useful for IDEs to change
> the default, possible with other args (like breakpoints and colors) bound to
> the callab
On 7 September 2017 at 19:17, Barry Warsaw wrote:
> On Sep 7, 2017, at 18:12, Nick Coghlan wrote:
>>
>> Related to this is the suggestion that we make the default
>> sys.breakpointhook() a no-op, so that accidentally checking in calls
>> to breakpoint() won' t hang CI systems.
>>
>> Then folks th
On Sep 7, 2017, at 18:12, Nick Coghlan wrote:
>
> Related to this is the suggestion that we make the default
> sys.breakpointhook() a no-op, so that accidentally checking in calls
> to breakpoint() won' t hang CI systems.
>
> Then folks that wanted to use the functionality would set
> "PYTHONBRE
On Sep 7, 2017, at 16:58, Gregory P. Smith wrote:
> Input from OS package distributors would be interesting. Would they use this?
I suspect it won’t be that interesting to the Debian ecosystem, since we
generate pyc files on package install. We do that because we can support
multiple version
On Thu, Sep 7, 2017, at 16:58, Gregory P. Smith wrote:
> +1 on this PEP.
Thanks!
> Questions:
>
> Input from OS package distributors would be interesting. Would they use
> this? Which way would it impact their startup time (loading the .py file
> vs just statting it. does that even matter?
On 7 September 2017 at 16:58, Gregory P. Smith wrote:
> +1 on this PEP.
>
> The TL;DR summary of this PEP:
> The pyc date+length metadata check was a convenient hack. It still works
> well for many people and use cases, it isn't going away.
> PEP 552 proposes a new alternate hack that relies
On 7 September 2017 at 11:43, Barry Warsaw wrote:
> Environment variable
>
>
> Should we add an environment variable so that ``sys.breakpointhook()``
> can be
> set outside of the Python invocation? E.g.::
>
> $ export PYTHONBREAKPOINTHOOK=my.debugger:Debugger
>
> This wo
On 2017-09-07 23:00:43 +, Barry Warsaw said:
On Sep 7, 2017, at 14:25, Barry Warsaw wrote:
I’ll see what it takes to add `header` to pdb.set_trace(), but I’ll do
that as a separate PR (i.e. not as part of this PEP).
Turns out to be pretty easy.
https://bugs.python.org/issue31389
https
On 9/7/2017 4:19 PM, Terry Reedy wrote:
A somewhat separate point: the name breakpoint() is slightly
misleading, which has consequences if it is (improperly) called more
than once. While breakpoint() acts as a breakpoint, what it does (at
least in the default pdb case) is *initialize* and start
On 7 September 2017 at 07:06, Ethan Furman wrote:
> The concern is *how* PEP 550 provides it:
>
> - explicitly, like threading.local(): has to be set up manually,
> preferably with a context manager
>
> - implicitly: it just happens under certain conditions
A recurring point of confusion with t
+1 on this PEP.
The TL;DR summary of this PEP:
The pyc date+length metadata check was a convenient hack. It still works
well for many people and use cases, it isn't going away.
PEP 552 proposes a new alternate hack that relies on file contents
instead of os and filesystem date metadata.
A
Elvis Pranskevichus wrote:
By default, generators reference an empty LogicalContext object that is
allocated once (like the None object). We can do that because LCs are
immutable.
Ah, I see. That wasn't clear from the implementation, where
gen.__logical_context__ = contextvars.LogicalCon
On 9/7/2017 12:52 PM, Barry Warsaw wrote:
On Sep 7, 2017, at 07:46, Guido van Rossum wrote:
Without following all this (or the PEP, yet) super exactly, does this mean you
are satisfied with what the PEP currently proposes or would you like changes?
It's a little unclear from what you wrote.
On Sep 7, 2017, at 14:25, Barry Warsaw wrote:
>
> I’ll see what it takes to add `header` to pdb.set_trace(), but I’ll do that
> as a separate PR (i.e. not as part of this PEP).
Turns out to be pretty easy.
https://bugs.python.org/issue31389
https://github.com/python/cpython/pull/3438
Cheers,
On 09/07/2017 03:49 PM, Larry Hastings wrote:
Excluding Lib/test, there are 375 uses of "@property" in the stdlib in
trunk, 60 uses of __getattr__, and 34 of __getattribute__.
I spent a minute looking at the output and realized there were a bunch
of hits inside pydoc_data/topics.py, aka docu
On 09/06/2017 09:45 AM, Guido van Rossum wrote:
So we're looking for a competing PEP here. Shouldn't be long, just
summarize the discussion about use cases and generality here.
I don't think it's necessarily a /competing/ PEP; in my opinion, they
serve slightly different use cases. After al
On Thu, Sep 7, 2017, at 14:43, Guido van Rossum wrote:
> On Thu, Sep 7, 2017 at 2:40 PM, Benjamin Peterson
> wrote:
>
> >
> >
> > On Thu, Sep 7, 2017, at 14:19, Guido van Rossum wrote:
> > > Nice one.
> > >
> > > It would be nice to specify the various APIs needed as well.
> >
> > The compileal
On Thu, Sep 7, 2017, at 14:54, Antoine Pitrou wrote:
> On Thu, 07 Sep 2017 14:32:19 -0700
> Benjamin Peterson wrote:
> > >
> > > Not sure how common that situation is (certainly the source tree wasn't
> > > read-only when you checked it out or untar'ed it), but isn't it easily
> > > circumvente
On Thu, 07 Sep 2017 14:40:33 -0700
Benjamin Peterson wrote:
> On Thu, Sep 7, 2017, at 14:19, Guido van Rossum wrote:
> > Nice one.
> >
> > It would be nice to specify the various APIs needed as well.
>
> The compileall and py_compile ones?
>
> >
> > Why do you keep the mtime-based format as
On Thu, 07 Sep 2017 14:32:19 -0700
Benjamin Peterson wrote:
> >
> > Not sure how common that situation is (certainly the source tree wasn't
> > read-only when you checked it out or untar'ed it), but isn't it easily
> > circumvented by copying the source tree before building?
>
> Well, yes, in
On Thu, Sep 7, 2017 at 2:40 PM, Benjamin Peterson
wrote:
>
>
> On Thu, Sep 7, 2017, at 14:19, Guido van Rossum wrote:
> > Nice one.
> >
> > It would be nice to specify the various APIs needed as well.
>
> The compileall and py_compile ones?
>
Yes, and the SipHash mod to specify the key you menti
On Thu, Sep 7, 2017, at 14:19, Guido van Rossum wrote:
> Nice one.
>
> It would be nice to specify the various APIs needed as well.
The compileall and py_compile ones?
>
> Why do you keep the mtime-based format as an option? (Maybe because it's
> faster? Did you measure it?)
I haven't actual
On Thu, Sep 7, 2017, at 14:21, Antoine Pitrou wrote:
> On Thu, 07 Sep 2017 14:08:58 -0700
> Benjamin Peterson wrote:
> > On Thu, Sep 7, 2017, at 14:00, Antoine Pitrou wrote:
> > > On Thu, 07 Sep 2017 13:39:21 -0700
> > > Benjamin Peterson wrote:
> > > > Hello,
> > > > I've written a short PEP
On Thu, Sep 7, 2017, at 14:19, Freddy Rietdijk wrote:
> > The main objection to that model is that it requires modifying source
> timestamps, which isn't possible for builds on read-only source trees.
>
> Why not set the source timestamps of the source trees to say 1 first?
If the source-tree i
On Sep 7, 2017, at 12:09, Fernando Perez wrote:
>> The PEP has an open issue regarding breakpoint() taking *args and **kws,
>> which would just be passed through the call stack. It sounds like you’d be
>> in favor of that enhancement.
>
> If you go witht the `(*a, **k)` pass-through API, would
On Thu, 07 Sep 2017 14:08:58 -0700
Benjamin Peterson wrote:
> On Thu, Sep 7, 2017, at 14:00, Antoine Pitrou wrote:
> > On Thu, 07 Sep 2017 13:39:21 -0700
> > Benjamin Peterson wrote:
> > > Hello,
> > > I've written a short PEP about an import extension to allow pycs to be
> > > more determinist
On Sep 7, 2017, at 13:52, Terry Reedy wrote:
> pdb.set_trace is a public and stable interface. IDLE's is private and likely
> to be initially unstable. I can imagine that the function that I would want
> to bind to sys.__breakpoint__ would be a bound method
To be pedantic, you’re not suppos
Nice one.
It would be nice to specify the various APIs needed as well.
Why do you keep the mtime-based format as an option? (Maybe because it's
faster? Did you measure it?)
On Thu, Sep 7, 2017 at 1:39 PM, Benjamin Peterson
wrote:
> Hello,
> I've written a short PEP about an import extension t
> The main objection to that model is that it requires modifying source
timestamps, which isn't possible for builds on read-only source trees.
Why not set the source timestamps of the source trees to say 1 first?
That's what is done with the Nix package manager. The Python interpreter is
patched (
On Sep 7, 2017, at 14:04, Fred Drake wrote:
>
> On Thu, Sep 7, 2017 at 4:52 PM, Terry Reedy wrote:
>> Environmental variables tend to be a pain on Windows and nigh unusable by
>> beginners. Leaving that aside, I see these problems with trying to use one
>> for IDLE's *current* debugger.
>>
>>
On Thu, Sep 7, 2017, at 14:00, Antoine Pitrou wrote:
> On Thu, 07 Sep 2017 13:39:21 -0700
> Benjamin Peterson wrote:
> > Hello,
> > I've written a short PEP about an import extension to allow pycs to be
> > more deterministic by optional replacing the timestamp with a hash of
> > the source file
On Thu, Sep 7, 2017 at 4:52 PM, Terry Reedy wrote:
> Environmental variables tend to be a pain on Windows and nigh unusable by
> beginners. Leaving that aside, I see these problems with trying to use one
> for IDLE's *current* debugger.
>
> pdb is universal, in the sense of working with any pytho
On Thu, 07 Sep 2017 13:39:21 -0700
Benjamin Peterson wrote:
> Hello,
> I've written a short PEP about an import extension to allow pycs to be
> more deterministic by optional replacing the timestamp with a hash of
> the source file: https://www.python.org/dev/peps/pep-0552/
Why isn't https://gith
On 9/7/2017 12:50 PM, Barry Warsaw wrote:
On Sep 6, 2017, at 23:10, Terry Reedy wrote:
Environmental variables are set to strings, not objects. It is not clear how
you intend to handle the conversion.
The environment variable names a module import path. Without quibbling about
the detail
Hello,
I've written a short PEP about an import extension to allow pycs to be
more deterministic by optional replacing the timestamp with a hash of
the source file: https://www.python.org/dev/peps/pep-0552/
Thanks for reading,
Benjamin
P.S. I came up with the idea for this PEP while awake.
__
On 2017-09-07 00:20:17 +, Barry Warsaw said:
Thanks Fernando, this is exactly the kind of feedback from other
debuggers that I’m looking for. It certainly sounds like a handy
feature; I’ve found myself wanting something like that from pdb from
time to time.
Glad it's useful, thanks for
Thanks for all the great feedback folks! Here then is PEP 553 version
2. The notable changes are:
* Change the name of the built-in from debug() to breakpoint()
* Modify the signature to be breakpoint(*args, **kws)
https://www.python.org/dev/peps/pep-0553/
Included below for convenience.
Chee
On Thu, 7 Sep 2017 11:30:12 -0600
Neil Schemenauer wrote:
>
> * The GC process would work nearly the same as it does now. Rather than
> only traversing the linked list, we would also have to crawl over the
> GC object arenas, check blocks of memory that have the tracked bit
> set.
Small n
Larry Hastings wrote:
> The TL;DR summary: add support for property objects to modules.
> I've already posted a prototype.
I posted an idea to python-ideas about lazy module loading. If the
lazy loading idea works, having properties would allow modules to
continue to be "lazy safe" but to easily
Is there any issue with unit-at-a-time optimization? I would
imagine that a static global would allow optimizations that are not
safe for a exported global (not sure the C term for it).
I suspect it doesn't matter and I support the idea in general.
Global variables in extension modules kills the
Python objects that participate in cyclic GC (things like lists, dicts,
sets but not strings, ints and floats) have extra memory overhead. I
think it is possible to mostly eliminate this overhead. Also, while
the GC is running, this GC state is mutated, which destroys
copy-on-write optimizations.
On Sep 7, 2017, at 10:00, Christian Heimes wrote:
> Setuptools' entry points [1] use colon between import and function, e.g.
> "pdb:set_trace" would import pdb and then execute set_trace. The
> approach can be augmented to allow calling a class method, too.
>
> So
>
> "package.module:myclass.c
This is now in git master after being merged by Victor in
https://github.com/python/cpython/pull/3385.
Regards
Antoine.
On Tue, 5 Sep 2017 18:36:51 +0200
Antoine Pitrou wrote:
> Hello,
>
> It's 2017 and we are still allowing people to compile CPython without
> threads support. It adds some
On 2017-09-07 09:50, Barry Warsaw wrote:
> On Sep 6, 2017, at 23:10, Terry Reedy wrote:
>>
>> Environmental variables are set to strings, not objects. It is not clear
>> how you intend to handle the conversion.
>
> The environment variable names a module import path. Without quibbling about
>
On Sep 7, 2017, at 07:46, Guido van Rossum wrote:
> Without following all this (or the PEP, yet) super exactly, does this mean
> you are satisfied with what the PEP currently proposes or would you like
> changes? It's a little unclear from what you wrote.
I’m also unsure whether Terry is good
On Sep 6, 2017, at 23:10, Terry Reedy wrote:
>
> Environmental variables are set to strings, not objects. It is not clear how
> you intend to handle the conversion.
The environment variable names a module import path. Without quibbling about
the details of the syntax (because honestly, I’m n
On Wed, Sep 6, 2017 at 11:59 PM, Terry Reedy wrote:
> On 9/6/2017 6:45 PM, Barry Warsaw wrote:
>
>> On Sep 6, 2017, at 14:59, Terry Reedy wrote:
>>
>>>
>>> Currently, the debugger is started in response to a menu seletion in the
>>> IDLE process while the python process is idle. One reason for
On Thu, Sep 07, 2017 at 09:41:10AM -0400, Elvis Pranskevichus wrote:
> threading.local(), the isolation mechanism, is *implicit*.
> decimal.localcontext() is an *explicit* resource manager that relies on
> threading.local() magic. PEP 550 simply provides a threading.local()
> alternative that
I write it in a new thread, but I also want to write it here -- I need a
time out in this discussion so I can think about it more.
--
--Guido van Rossum (python.org/~guido)
___
Python-Dev mailing list
Python-Dev@python.org
https://mail.python.org/mailma
I am declaring a time out for discussing of PEP 550 and its competitor, PEP
555. There has been some good discussion but also some mud-slinging (in
various directions), and I've been frankly overwhelmed by the exchanges,
despite having spent much of Tuesday talking to Yury about it and lying
awake
On Wed, Sep 6, 2017 at 8:17 PM, Benjamin Peterson
wrote:
> On Wed, Sep 6, 2017, at 10:08, Antoine Pitrou wrote:
> > On Wed, 06 Sep 2017 09:42:29 -0700
> > Benjamin Peterson wrote:
> > > On Wed, Sep 6, 2017, at 03:14, Antoine Pitrou wrote:
> > > >
> > > > Hello,
> > > >
> > > > I'm a bit concerne
On Thursday, September 7, 2017 10:06:14 AM EDT Ethan Furman wrote:
> I might be, and I wouldn't be surprised. :) On the other hand, one
> can look at isolation as being a resource.
> > threading.local(), the isolation mechanism, is *implicit*.
>
> I don't think so. You don't get threading.local
On Thursday, September 7, 2017 6:37:58 AM EDT Greg Ewing wrote:
> 2) You ignore it and always use a context manager, in
> which case it's not strictly necessary for the implicit
> context push to occur, since the relevant context managers
> can take care of it.
>
> So there doesn't seem to be any
On Thursday, September 7, 2017 9:05:58 AM EDT Ethan Furman wrote:
> The disagreement seems to be whether a LogicalContext should be
> created implicitly vs explicitly (or opt-out vs opt-in). As a user
> trying to track down a decimal context change not propagating, I
> would not suspect the above c
On Wed, Sep 6, 2017 at 8:17 PM, Benjamin Peterson
wrote:
> On Wed, Sep 6, 2017, at 10:08, Antoine Pitrou wrote:
> > On Wed, 06 Sep 2017 09:42:29 -0700
> > Benjamin Peterson wrote:
> > > On Wed, Sep 6, 2017, at 03:14, Antoine Pitrou wrote:
> > > >
> > > > Hello,
> > > >
> > > > I'm a bit concerne
On 09/07/2017 06:41 AM, Elvis Pranskevichus wrote:
On Thursday, September 7, 2017 9:05:58 AM EDT Ethan Furman wrote:
The disagreement seems to be whether a LogicalContext should be
created implicitly vs explicitly (or opt-out vs opt-in). As a user
trying to track down a decimal context change
On Thursday, September 7, 2017 3:54:15 AM EDT Greg Ewing wrote:
> This problem would also not arise if context vars
> simply had names instead of being magic key objects:
>
> def foo():
>contextvars.set("mymodule.myvar", 1)
>
> That's another thing I think would be an improvement,
> b
On 09/06/2017 11:57 PM, Yury Selivanov wrote:
On Wed, Sep 6, 2017 at 11:39 PM, Greg Ewing wrote:
Here's one way that refactoring could trip you up.
Start with this:
async def foo():
calculate_something()
#in a coroutine, so we can be lazy and not use a cm
Where exactly doe
On Tue, Sep 5, 2017 at 6:10 PM, Mariatta Wijaya
wrote:
> Hi,
>
> The cherry picker bot has just been deployed to CPython repo, codenamed
> miss-islington.
>
> miss-islington made the very first backport PR for CPython and became a
> first time GitHub contributor: https://github.com/python/cpython
On 09/07/2017 03:37 AM, Greg Ewing wrote:
If I understand correctly, instead of using a context
manager, your fractions example could be written like
this:
def fractions(precision, x, y):
ctx = decimal.getcontext().copy()
decimal.setcontext(ctx)
ctx.prec = precision
yield My
On 09/07/2017 04:39 AM, Greg Ewing wrote:
1) Under "Generators" it says:
once set in the generator, the context variable is guaranteed
not to change between iterations;
This suggests that you're not allowed to set() a given
context variable more than once in a given generator,
but some
There are a couple of things in the PEP I'm confused about:
1) Under "Generators" it says:
once set in the generator, the context variable is guaranteed
not to change between iterations;
This suggests that you're not allowed to set() a given
context variable more than once in a given gene
There is one thing I misunderstood. Since generators and
coroutines are almost exactly the same underneath, I had
thought that the automatic logical_context creation for
generators was also going to apply to coroutines, but
from reading the PEP again it seems that's not the case.
Somehow I missed
On Thu, Sep 7, 2017 at 10:54 AM, Greg Ewing
wrote:
> Yury Selivanov wrote:
>
>> def foo():
>> var = ContextVar()
>> var.set(1)
>>
>> for _ in range(10**6): foo()
>>
>> If 'var' is strongly referenced, we would have a bunch of them.
>>
>
> Erk. This is not how I envisaged
Yury Selivanov wrote:
I understand what Koos is
talking about, but I really don't follow you. Using the
"with-statements to be skipped" language is very confusing and doesn't
help to understand you.
If I understand correctly, instead of using a context
manager, your fractions example could be
I've proposed a PEP 11 update in this PR:
https://github.com/python/peps/pull/394
Regards
Antoine.
On Tue, 5 Sep 2017 18:36:51 +0200
Antoine Pitrou wrote:
> Hello,
>
> It's 2017 and we are still allowing people to compile CPython without
> threads support. It adds some complication in sever
Yury Selivanov wrote:
def foo():
var = ContextVar()
var.set(1)
for _ in range(10**6): foo()
If 'var' is strongly referenced, we would have a bunch of them.
Erk. This is not how I envisaged context vars would be
used. What I thought you would do is this:
my_contex
Yury Selivanov wrote:
The PEP gives you a Task Local Storage, where Task is:
1. your single-threaded code
2. a generator
3. an async task
If you correctly use context managers, PEP 550 works intuitively and
similar to how one would think that threading.local() should work.
My version works *m
Yury Selivanov wrote:
1. So essentially this means that we will have one "local context" per
context manager storing one value.
I can't see that being a major problem. Context vars will
(I hope!) be very rare things, and needing to change a
bunch of them in one function ought to be rarer still.
On Wed, Sep 6, 2017 at 11:55 PM, Greg Ewing wrote:
> Guido van Rossum wrote:
>>
>> Yeah, so my claim this is simply a non-problem, and you've pretty much
>> just proved that by failing to come up with pointers to actual code that
>> would suffer from this. Clearly you're not aware of any such code
Yury Selivanov wrote:
I still think that giving Python programmers one strong rule: "context
mutation is always isolated in generators" makes it easier to reason
about the EC and write maintainable code.
Whereas I think it makes code *harder* to reason about,
because to take advantage of it you
On 9/6/2017 6:45 PM, Barry Warsaw wrote:
On Sep 6, 2017, at 14:59, Terry Reedy wrote:
Currently, the debugger is started in response to a menu seletion in the IDLE
process while the python process is idle. One reason for the 'idle'
requirement' is because when code is exec-uting, the loop t
On Wed, Sep 6, 2017 at 11:39 PM, Greg Ewing wrote:
> Yury Selivanov wrote:
>>
>> It would be great if you or Greg could show a couple of real-world
>> examples showing the "issue" (with the current PEP 550
>> APIs/semantics).
>
>
> Here's one way that refactoring could trip you up.
> Start with th
79 matches
Mail list logo
