On Fri, Sep 8, 2017 at 8:54 PM, Michel Desmoulin
wrote:
>
> Le 09/09/2017 à 01:28, Stefan Krah a écrit :
>> Still, the argument "who uses subinterpreters?" of course still remains.
>
> For now, nobody. But if we expose it and web frameworks manage to create
> workers as fast as multiprocessing and
On 9/7/2017 10:45 PM, Barry Warsaw wrote:
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 breakpo
Le 09/09/2017 à 01:28, Stefan Krah a écrit :
> On Fri, Sep 08, 2017 at 04:04:27PM -0700, Eric Snow wrote:
>> * "stdlib support for subinterpreters adds extra burden
>> on C extension authors"
>>
>> In the ``Interpreter Isolation`` section below we identify ways in
>> which isolation in CPython'
[Tim]
>> In that case, it's because Python
>> _does_ mutate the objects' refcount members under the covers, and so
>> the OS ends up making fresh copies of the memory anyway.
[Greg Ewing ]
> Has anyone ever considered addressing that by moving the
> refcounts out of the objects and keeping them so
Tim Peters wrote:
In that case, it's because Python
_does_ mutate the objects' refcount members under the covers, and so
the OS ends up making fresh copies of the memory anyway.
Has anyone ever considered addressing that by moving the
refcounts out of the objects and keeping them somewhere
else
On Fri, Sep 08, 2017 at 04:04:27PM -0700, Eric Snow wrote:
> * "stdlib support for subinterpreters adds extra burden
> on C extension authors"
>
> In the ``Interpreter Isolation`` section below we identify ways in
> which isolation in CPython's subinterpreters is incomplete. Most
> notable is e
On 9 September 2017 at 01:00, Guido van Rossum wrote:
> I think it would be useful to write 1-2 sentences about the problem with
> inheritance -- in that case you pretty much have to use a metaclass,
>
>
It is not the case now. I think __init_subclass__ has almost the same
possibilities as a deco
On 2017-09-08 07:57, Eric V. Smith wrote:
I've written a PEP for…
Apologies for the following list dumb questions and bikesheds:
- 'Classes can be thought of as "mutable namedtuples with defaults".'
- A C/C++ (struct)ure sounds like a simpler description that many more
would understan
I've updated the PEP in response to some excellent feedback. Thanks
to all who helped. Most notably, I've added a basic object passing
mechanism. I've included the PEP below. Please let me know what you
think. Thanks!
-eric
PEP: 554
Title
I think it would be useful to write 1-2 sentences about the problem with
inheritance -- in that case you pretty much have to use a metaclass, and
the use of a metaclass makes life harder for people who want to use their
own metaclass (since metaclasses don't combine without some manual
intervention
On 9/8/17 3:20 PM, Mike Miller wrote:
On 2017-09-08 07:57, Eric V. Smith wrote:
I've written a PEP for…
Apologies for the following list dumb questions and bikesheds:
- 'Classes can be thought of as "mutable namedtuples with defaults".'
- A C/C++ (struct)ure sounds like a simpler descrip
On 9 September 2017 at 00:14, Antoine Pitrou wrote:
> On Fri, 8 Sep 2017 16:59:57 +0200
> Ivan Levkivskyi wrote:
>
> > I already made a PR that would highlight code in PEPs half-year ago, but
> it
> > was rejected with the reason that they will be moved to RtD soon.
>
> Perhaps we can revive tha
On 2017-09-08 07:57, Eric V. Smith wrote:
I've written a PEP for…
Apologies for the following list dumb questions and bikesheds:
- 'Classes can be thought of as "mutable namedtuples with defaults".'
- A C/C++ (struct)ure sounds like a simpler description that many more
would understan
>
> For some unknown value of "soon". :-(
Well as soon as these tasks are done:
https://github.com/python/peps/projects/1
Mariatta Wijaya
___
Python-Dev mailing list
Python-Dev@python.org
https://mail.python.org/mailman/listinfo/python-dev
Unsubscrib
On Fri, 8 Sep 2017 16:59:57 +0200
Ivan Levkivskyi wrote:
> I already made a PR that would highlight code in PEPs half-year ago, but it
> was rejected with the reason that they will be moved to RtD soon.
Perhaps we can revive that PR? Browsing through old peps PRs, I can
see that other people we
For some unknown value of "soon". :-(
On Fri, Sep 8, 2017 at 7:59 AM, Ivan Levkivskyi
wrote:
> I already made a PR that would highlight code in PEPs half-year ago, but
> it was rejected with the reason that they will be moved to RtD soon.
>
> --
> Ivan
>
> 8 Вер 2017 16:56 "Antoine Pitrou" пише
For your information,
You can now automatically compile and check the ssl module with multiple
versions of OpenSSL and LibreSSL. The multissltest script downloads
tar.gz, compiles the source and installs headers + shared lib into a
local directory. It takes rather long the first time because OpenS
On 09/08/2017 01:45 PM, Ethan Furman wrote:
I will admit I don't see what reassigning the __class__ attribute on a module
did for us.
Nathaniel Smith wrote:
-
> If you have an existing package that doesn't replace itself in
> sys.modules, then it's difficult and risky to s
On Fri, Sep 8, 2017 at 1:45 PM, Ethan Furman wrote:
> On 09/08/2017 12:44 PM, Larry Hastings wrote:
>
>> I've updated PEP 549 with a new title--"Instance Descriptors" is a better
>> name than "Instance Properties"--and to
>> clarify my rationale for the PEP. I've also updated the prototype with
>
Assigning the module's __class__ means you can otherwise initialize your
module instance normally--all your class needs to do is declare your
properties or magic methods. If you overwrite the sys.modules entry for
your module with a new instance of a custom subclass, all your module
initiali
On 09/08/2017 12:44 PM, Larry Hastings wrote:
I've updated PEP 549 with a new title--"Instance Descriptors" is a better name than
"Instance Properties"--and to
clarify my rationale for the PEP. I've also updated the prototype with code
cleanups and a new type:
"collections.abc.InstanceDescrip
[Neil Schemenauer ]
> 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
On Fri, Sep 8, 2017 at 12:52 PM Antoine Pitrou wrote:
> On Fri, 8 Sep 2017 12:40:34 -0700
> Nathaniel Smith wrote:
> >
> > PyPy just abandons everything when shutting down, instead of running
> > finalizers. See the last paragraph of :
> >
> http://doc.pypy.org/en/latest/cpython_differences.html
On Fri, 8 Sep 2017 12:40:34 -0700
Nathaniel Smith wrote:
>
> PyPy just abandons everything when shutting down, instead of running
> finalizers. See the last paragraph of :
> http://doc.pypy.org/en/latest/cpython_differences.html#differences-related-to-garbage-collection-strategies
>
> So that mi
On 09/08/2017 12:30 PM, Benjamin Peterson wrote:
On Fri, Sep 8, 2017, at 12:24, Larry Hastings wrote:
On 09/08/2017 12:04 PM, Benjamin Peterson wrote:
- Why not run all (Python) finalizers on the thread and not just ones
from cycles?
Two reasons:
1. Because some code relies on the final
I've updated PEP 549 with a new title--"Instance Descriptors" is a
better name than "Instance Properties"--and to clarify my rationale for
the PEP. I've also updated the prototype with code cleanups and a new
type: "collections.abc.InstanceDescriptor", a base class that allows
user classes
On Fri, Sep 8, 2017 at 12:13 PM, Antoine Pitrou wrote:
> On Fri, 08 Sep 2017 12:04:10 -0700
> Benjamin Peterson wrote:
>> I like it overall.
>>
>> - I was wondering what happens during interpreter shutdown. I see you
>> have that listed as a open issue. How about simply shutting down the
>> final
On Fri, Sep 8, 2017, at 12:13, Antoine Pitrou wrote:
> On Fri, 08 Sep 2017 12:04:10 -0700
> Benjamin Peterson wrote:
> > I like it overall.
> >
> > - I was wondering what happens during interpreter shutdown. I see you
> > have that listed as a open issue. How about simply shutting down the
> >
On Fri, Sep 8, 2017, at 12:24, Larry Hastings wrote:
>
>
> On 09/08/2017 12:04 PM, Benjamin Peterson wrote:
> > - Why not run all (Python) finalizers on the thread and not just ones
> > from cycles?
>
> Two reasons:
>
> 1. Because some code relies on the finalizer being called on the thread
On Fri, 08 Sep 2017 12:04:10 -0700
Benjamin Peterson wrote:
> I like it overall.
>
> - I was wondering what happens during interpreter shutdown. I see you
> have that listed as a open issue. How about simply shutting down the
> finalization thread and not guaranteeing that finalizers are actually
On 09/08/2017 12:04 PM, Benjamin Peterson wrote:
- Why not run all (Python) finalizers on the thread and not just ones
from cycles?
Two reasons:
1. Because some code relies on the finalizer being called on the thread
where the last reference is dropped. This is usually the same
thread
I like it overall.
- I was wondering what happens during interpreter shutdown. I see you
have that listed as a open issue. How about simply shutting down the
finalization thread and not guaranteeing that finalizers are actually
ever run à la Java?
- Why not run all (Python) finalizers on the thre
On 09/08/2017 11:38 AM, Steven D'Aprano wrote:
On Fri, Sep 08, 2017 at 10:37:12AM -0700, Nick Coghlan wrote:
def __eq__(self, other):
if other.__class__ is self.__class__:
return (self.name, self.unit_price, self.quantity_on_hand) ==
(other.name, other.unit_price, other.qua
On Fri, Sep 08, 2017 at 10:37:12AM -0700, Nick Coghlan wrote:
> > def __eq__(self, other):
> > if other.__class__ is self.__class__:
> > return (self.name, self.unit_price, self.quantity_on_hand) ==
> > (other.name, other.unit_price, other.quantity_on_hand)
> > return NotIm
Thank you all for the feedback. I've now updated the PEP to specify a
4-word pyc header with a bit field in every case.
On Fri, Sep 8, 2017, at 09:43, Nick Coghlan wrote:
> On 8 September 2017 at 07:55, Antoine Pitrou wrote:
> > On Fri, 8 Sep 2017 07:49:46 -0700
> > Nick Coghlan wrote:
> >> > I'
On 8 September 2017 at 07:57, Eric V. Smith wrote:
> I've written a PEP for what might be thought of as "mutable namedtuples with
> defaults, but not inheriting tuple's behavior" (a mouthful, but it sounded
> simpler when I first thought of it). It's heavily influenced by the attrs
> project. It u
On 8 September 2017 at 08:58, Masayuki YAMAMOTO
wrote:
> Awesome! Thank you for accepting the PEP :)
> The only thing missing is a reference implementation, I'm going to complete.
>
> BTW, one of TSS keys is going to move to the runtime struct by bpo-30860
> "Consolidate stateful C globals under a
On Fri, 8 Sep 2017 10:03:33 -0700
Nick Coghlan wrote:
> On 8 September 2017 at 08:05, Antoine Pitrou wrote:
> >
> > Hello,
> >
> > I've written a PEP by which you can tell the GC to run in a dedicated
> > thread. The goal is to solve reentrancy issues with finalizers:
> > https://www.python.org
On 8 September 2017 at 08:50, Neil Schemenauer wrote:
> This should be pretty safe to do and should give a significant
> benefit in startup time and memory usage.
And given the extended pyc header being proposed in PEP 552, we'd be
able to include flags in the header to indicate that the pyc file
On 8 September 2017 at 08:05, Antoine Pitrou wrote:
>
> Hello,
>
> I've written a PEP by which you can tell the GC to run in a dedicated
> thread. The goal is to solve reentrancy issues with finalizers:
> https://www.python.org/dev/peps/pep-0556/
+1 from me for the general concept. (Minor naming
On 8 September 2017 at 07:55, Antoine Pitrou wrote:
> On Fri, 8 Sep 2017 07:49:46 -0700
> Nick Coghlan wrote:
>> > I'd rather a single magic number and a separate bitfield that tells
>> > what the header encodes exactly. We don't *have* to fight for a tiny
>> > size reduction of pyc files.
>>
>>
On 9/8/17 9:07 AM, Eric V. Smith wrote:
Hah! Thanks for the catch.
I've pushed a fix to the PEP repo, it should show up online shortly.
Eric.
There is no C in my happy place.
--
Eric.
On Sep 8, 2017, at 8:52 AM, Paul Moore wrote:
On 8 September 2017 at 15:57, Eric V. Smith wrote:
I'v
ACTIVITY SUMMARY (2017-09-01 - 2017-09-08)
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:
open6149 (-17)
closed 36997 (+87)
total 43146 (+70)
Open issues wi
Hah! Thanks for the catch.
There is no C in my happy place.
--
Eric.
> On Sep 8, 2017, at 8:52 AM, Paul Moore wrote:
>
>> On 8 September 2017 at 15:57, Eric V. Smith wrote:
>> I've written a PEP for what might be thought of as "mutable namedtuples with
>> defaults, but not inheriting tuple'
Awesome! Thank you for accepting the PEP :)
The only thing missing is a reference implementation, I'm going to complete.
BTW, one of TSS keys is going to move to the runtime struct by bpo-30860
"Consolidate stateful C globals under a single struct". Although that's PR
was merged, the issue status
Barry Warsaw writes:
> and you would drop into the debugger after foo() but before bar().
> More rationale and details are provided in the PEP:
>
> https://www.python.org/dev/peps/pep-0553/
>
> Unlike David, but like Larry, I have a prototype implementation:
>
> https://github.c
Interesting. I note that this under "Specification":
"""
field's may optionally specify a default value, using normal Python syntax:
@dataclass
class C:
int a # 'a' has no default value
int b = 0 # assign a default value for 'b'
"""
...does not look like "normal Python syntax".
On 8 September 2017 at 15:57, Eric V. Smith wrote:
> I've written a PEP for what might be thought of as "mutable namedtuples with
> defaults, but not inheriting tuple's behavior" (a mouthful, but it sounded
> simpler when I first thought of it). It's heavily influenced by the attrs
> project. It u
This is an idea that came out of the lazy module loading (via AST
analysis), posted to python-ideas. The essential idea is to split
the marshal data stored in the .pyc into smaller pieces and only
load the parts as they are accessed. E.g. use a __getattr__ hook on
the module to unmarshal+exec the
Oops, I forgot the link. It should show up shortly at
https://www.python.org/dev/peps/pep-0557/.
Eric.
On 9/8/17 7:57 AM, Eric V. Smith wrote:
I've written a PEP for what might be thought of as "mutable namedtuples
with defaults, but not inheriting tuple's behavior" (a mouthful, but it
sounded
Hello,
I've written a PEP by which you can tell the GC to run in a dedicated
thread. The goal is to solve reentrancy issues with finalizers:
https://www.python.org/dev/peps/pep-0556/
Regards
Antoine.
PS: I did not come up with the idea for this PEP while other people
were having nightmares.
I already made a PR that would highlight code in PEPs half-year ago, but it
was rejected with the reason that they will be moved to RtD soon.
--
Ivan
8 Вер 2017 16:56 "Antoine Pitrou" пише:
>
> Hi,
>
> Is it possible to install pygments on the machine which builds and
> renders PEPs? It would
I've written a PEP for what might be thought of as "mutable namedtuples
with defaults, but not inheriting tuple's behavior" (a mouthful, but it
sounded simpler when I first thought of it). It's heavily influenced by
the attrs project. It uses PEP 526 type annotations to define fields.
From the
On 7 September 2017 at 20:02, Adrian Petrescu wrote:
> Would that not be a security concern, if you can get Python to execute
> arbitrary code just by setting an environment variable?
Not really, as once someone has write access to your process
environment, you've already lost (they can mess with
On Fri, 8 Sep 2017 07:49:46 -0700
Nick Coghlan wrote:
> On 8 September 2017 at 03:04, Antoine Pitrou wrote:
> > On Thu, 7 Sep 2017 18:47:20 -0700
> > Nick Coghlan wrote:
> >> However, I do wonder whether we could encode *all* the mode settings
> >> into the magic number, such that we did somet
Hi,
Is it possible to install pygments on the machine which builds and
renders PEPs? It would allow syntax highlighting in PEPs, making
example code more readable.
Regards
Antoine.
___
Python-Dev mailing list
Python-Dev@python.org
https://mail.pytho
On 8 September 2017 at 03:04, Antoine Pitrou wrote:
> On Thu, 7 Sep 2017 18:47:20 -0700
> Nick Coghlan wrote:
>> However, I do wonder whether we could encode *all* the mode settings
>> into the magic number, such that we did something like reserving the
>> top 3 bits for format flags:
>>
>> * num
I also like having the header fixed-size, so it might be possible to
rewrite headers (e.g. to flip the source bit) without moving the rest of
the file.
On Fri, Sep 8, 2017 at 3:38 AM, Antoine Pitrou wrote:
> On Fri, 8 Sep 2017 12:04:52 +0200
> Antoine Pitrou wrote:
> > On Thu, 7 Sep 2017 18:47:
On 8 September 2017 at 00:30, Masayuki YAMAMOTO
wrote:
> Hi folks,
>
> I submit PEP 539 third draft for the finish. Thank you for all the advice
> and the help!
Thank you Erik & Yamamoto-san for all of your work on this PEP!
The updates look good, so I'm happy to say as BDFL-Delegate that this
p
-BEGIN PGP SIGNED MESSAGE-
Hash: SHA256
It would appear to be more secure to define specific meanings for
particular values of the environment variable. S
-BEGIN PGP SIGNATURE-
Version: CryptUp 4.4.3 Gmail Encryption https://cryptup.org
Comment: Seamlessly send, receive and search
On Fri, 8 Sep 2017 12:04:52 +0200
Antoine Pitrou wrote:
> On Thu, 7 Sep 2017 18:47:20 -0700
> Nick Coghlan wrote:
> > However, I do wonder whether we could encode *all* the mode settings
> > into the magic number, such that we did something like reserving the
> > top 3 bits for format flags:
> >
On Thu, 7 Sep 2017 18:47:20 -0700
Nick Coghlan wrote:
> However, I do wonder whether we could encode *all* the mode settings
> into the magic number, such that we did something like reserving the
> top 3 bits for format flags:
>
> * number & 0x1FFF -> the traditional magic number
> * number & 0x8
Hi folks,
I submit PEP 539 third draft for the finish. Thank you for all the advice
and the help!
Summary of technical changes:
* Don't use `bool` types in the implementation, per discussion at
python/cpython#1362 [1]
* Update for removal of --without-threads
Best regards,
Masayuki
[1]: https:
63 matches
Mail list logo
