David Cuthbert added the comment:
On the completely deprecate reuse_address and rewrite/force folks to use
reuse_port proposals, I'm a bit dubious of this approach.
Right now, we have two knobs that directly correspond to (potential)
kernel-level socket parameters, SO_REUSEADDR
David Cuthbert added the comment:
Jukka -- Fair enough; will reword this a bit. I'm trying to keep the
DeprecationWarning short enough so people's eyes don't glaze over; will see
what wordsmithing I can do here. (Once you get beyond a certain length, the
number of folks who actually read
David Cuthbert added the comment:
Alright -- my first stab at the DeprecationWarning in 3.6.
https://github.com/dacut/cpython/commit/6a1e261678975e2c70ec6b5e98e8affa28702312
Please critique away, and don't fret about bruising my ego. :-)
Is there a more idiomatic way of getting a warning
David Cuthbert added the comment:
FreeBSD 12.1 and MacOS 10.15.1 (Catalina) appear to have saner and safer
behavior.
Both require the use of SO_REUSEPORT for this behavior to happen as well.
FreeBSD also requires the UID to be the same or 0 for subsequent processes to
make the bind() call
David Cuthbert added the comment:
I'm working on patches for the deprecation bits (targeting 3.6 for now; will
work my way up from there) for review, including documentation. Unless someone
tells me to stop. :-)
In an attempt to make this not-so-Linux-specific, I'm reviewing how this works
David Cuthbert added the comment:
How much harm would there be in bringing the DeprecationWarning into the next
patch of existing (3.6, 3.7, 3.8) releases? The security implications are
significant enough that I'd want to be notified of it in my software ASAP.
Users can (and should
Change by David Cuthbert :
--
versions: +Python 3.8
___
Python tracker
<https://bugs.python.org/issue34820>
___
___
Python-bugs-list mailing list
Unsubscribe:
David Cuthbert added the comment:
I'm seeing this on a rebuild now of Python 3.7.4 on Ubuntu 18.04 (in my case
against _ssl.c).
What's happening is there's coverage/profiling data being generated in the
build chain (somewhere), which spits out files named *.gcda. Interestingly,
make clean
David Cuthbert <da...@kanga.org> added the comment:
Oops, I wasn't looking broadly enough. This is also used in the augmented
assignment statements syntax, e.g. a += 1, 2, 3
--
___
Python tracker <rep...@bugs.python.org>
<https://
David Cuthbert <da...@kanga.org> added the comment:
Hm... that leaves the only production for expression_list as:
subscription ::= primary "[" expression_list "]"
And I'm not sure that this shouldn't also be replaced by starred_list. It's not
accepted today, thou
David Cuthbert <da...@kanga.org> added the comment:
CLA processed, and BDFL has assented on python-dev. Serhiy, thoughts on next
steps?
--
___
Python tracker <rep...@bugs.python.org>
<https://bugs.python
Change by David Cuthbert <da...@kanga.org>:
--
keywords: +patch
pull_requests: +4446
stage: -> patch review
___
Python tracker <rep...@bugs.python.org>
<https://bugs.pyt
New submission from David Cuthbert <da...@kanga.org>:
This stems from a query on StackOverflow:
https://stackoverflow.com/questions/47272460/python-tuple-unpacking-in-return-statement/
Specifically, the following syntax is allowed:
def f():
rest = (4, 5, 6)
t = 1, 2, 3, *rest
baalbek wrote:
No, concurrent access is highly relevant; for example, on a team of
about 50 architects working on design and production drawings for a new
hospital, each floor was one 'drawing' (dwg file), and thus stored on
disk as a separate entity from the other floors.
Now, only one
baalbek wrote:
David Cuthbert wrote:
This does not mean the design itself should be stored as an RDBMS. As
I've stated previously, CAD data (both electrical and, it appears,
mechanical) does not lend itself to RDBMS relationship modeling.
I simply do not agree with this.
A CAD program
Terry Hancock wrote:
I disagree that transactions are bad for CAD -- they may have
a different semantic role and the needed granularity may be
different, but the need to roll data back to an earlier revision
is just as present in drawings as it is for code or financial
transactions.
Sure,
baalbek wrote:
CAD systems available today (Autocad, Archicad, Architectural Desktop,
etc) have one huge flaw: they don't store data to a SQL database, but to
binary files.
There's a reason for this. Most CAD data is not in a form (First Normal
Form) suitable for a relational database. In
Paddy wrote:
Unfortunately, Cadence got their first with their DFII environment for
Schematic based design and their Lisp based language SKILL
Well, SKILL (a Franz Lisp derivative) is very old and has some peculiar
design quirks. Interfacing with anything not written by Cadence or not
Mike Meyer wrote:
Just out of curiosity, is there an OS out there where you can have the
permissions needed to delete a directory without having the
permissions needed to create it appropriately?
Not an OS, but AFS has a wider set of permissions (RLIDWKA - which, if I
remember correctly, are
Paul Rubin wrote:
I don't think you want to do this. Runtime type tags and the overhead
of checking them on every operation will kill you all by themselves.
Processors like that haven't been used much as Lisp targets either,
for the same reasons. Pick a different language.
I was thinking
Ed Leafe wrote:
Should we have defensive code for every possible broken installation? We use
a lot of the Python standard library modules, many dbapi-compliant modules,
and, of course, wxPython. If someone mis-installs one of the pre-requisites,
do you expect Dabo to catch that and present
21 matches
Mail list logo
