"Martin v. Löwis" <[EMAIL PROTECTED]> writes:
> David Abrahams wrote:
>> It isn't completely clear which branch or tag to get, and Google
>> turned up no obvious documentation.
>
> http://svn.python.org/projects/python/tags/r242/
Thanks.
--
or the
weekly issue report. I have a patched version of that
report that adds the bug/enhancement info. I'll try to dig
it up this week; someone ping me if I forget :) It think
the patch will need to be updated based on Ezio's changes.
--David
do
reviews and say on the issue "I think this is commit ready" and have
the issue moved to 'commit review' stage. Do that a few times where
people who are already triagers/committers agree with you, and you'll
get triage privileges on the tracker.
--David
started at the Bloomberg sprint last month,
but nothing has been posted to the issue yet:
http://bugs.python.org/issue7687
Is Bluetooth 4.0 something different from what the socket module already
has?
--David
___
Python-Dev mailing list
Pytho
#x27;.
IMO, preventing someone from shooting themselves in the foot by modifying
something they shouldn't modify according to the API is not a Python
use case ("consenting adults").
> And with a bit more tinkering it's possible to crash Python. (I'll
> leave that as an exercise for the reader! :-))
Preventing a Python program from being able to crash the interpreter,
that's a use case :)
--David
___
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
g the decision to vary the data from what matches the state of the
object it came from an explicit one. That seems to fit the Python zen
("explicit is better than implicit").
So I'm changing my mind, and do consider this a valid use case, even
absent the crash.
--David
On Wed, 16 Jul 2014 14:04:29 -, dw+python-...@hmmz.org wrote:
> On Wed, Jul 16, 2014 at 09:47:59AM -0400, R. David Murray wrote:
>
> > It would be nice to be able to return a frozendict instead of having the
> > overhead of building a new dict on each call.
>
> There
On Wed, 16 Jul 2014 10:10:07 -0700, Devin Jeanpierre
wrote:
> On Wed, Jul 16, 2014 at 6:37 AM, R. David Murray
> wrote:
> > IMO, preventing someone from shooting themselves in the foot by modifying
> > something they shouldn't modify according to the API is no
t;
> This may actually motivate me to start working on a redesign of
> walkdir at some point, with scandir and DirEntry objects as the basis.
> My original approach was just too slow to be useful in practice (at
> least when working with trees on the scale of a
about this more, maybe it should be a class function, so that
> it wouldn't require an instance:
>
> str.sum( iterable_containing_strings )
>
> [ or str.join( iterable_containing_strings ) ]
That's how it used to be spelled in python2.
--David
_
about this more, maybe it should be a class function, so that
> it wouldn't require an instance:
>
> str.sum( iterable_containing_strings )
>
> [ or str.join( iterable_containing_strings ) ]
Sorry, I mean 'string.join' is how it used to be spelled. Making i
it pickleable, since the pickle protocol doesn't
call __init__.
--David
___
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
know the encoding of the filenames.
So, the way to look at this is that python3 is no worse[1] than python2 for
handling posix binary filenames, and also provides additional features
if you *do* know the correct encoding of the filenames.
--David
[1] modulo any remaining API bugs, which is
ss when the domain line (posix
binary filenames to consistently encoded text stream) are crossed. And
the result is more *valid* programs, and fewer unexpected errors
overall, with no inconvenience unless that domain line is crossed,
and even then the inconvenience is limited to the open call that c
On Sat, 23 Aug 2014 19:33:06 +0300, Marko Rauhamaa wrote:
> "R. David Murray" :
>
> > The same problem existed in python2 if your goal was to produce a stream
> > with a consistent encoding, but now python3 treats that as an error.
>
> I have a different int
On Tue, 26 Aug 2014 11:25:19 +0900, "Stephen J. Turnbull"
wrote:
> R. David Murray writes:
>
> > Also, as has been discussed in this thread previously, any program that
> > deals with filenames is dealing with human readable languages, even
> > if posix it
cluding the CLR) and the JVM adopted a different
> multilingual model, but still one that actually works: UTF-16-LE
This kind of puts the "length" of the python2->python3 transition
period in perspective, doesn't it?
--David
___
Pyth
t;
> > There'll be a surrogate escape if a byte couldn't be decoded, but just
> > because a byte could be decoded, it doesn't mean that it's correct.
> >
> > If you picked the wrong encoding, the other codepoints could be
On Thu, 28 Aug 2014 10:54:44 -0700, Glenn Linderman
wrote:
> On 8/28/2014 10:41 AM, R. David Murray wrote:
> > On Thu, 28 Aug 2014 10:15:40 -0700, Glenn Linderman
> > wrote:
> >> On 8/28/2014 12:30 AM, MRAB wrote:
> >>> There'll be a surrogate escap
f public certs that are problematic,
but I'd be willing to bet you that there are more not-really-public ones
that are critical to day to day operations *somewhere* :)
wget and curl have 'ignore validation' as a command line flag for a reason.
--David
_
On Fri, 29 Aug 2014 18:00:50 -0400, Donald Stufft wrote:
>
> On Aug 29, 2014, at 5:42 PM, R. David Murray wrote:
> > Especially if you want an accelerated change, there must be a way to
> > *easily* get back to the previous behavior, or we are going to catch a
> > lot
mplemented in python that does not itself provide a way to
disable the new default security (because it is *new*). Only an
environment variable will do that.
Since the environment variable is opt-in, I think the "consenting
adults" argument applies to Alex's demure about "mu
docs for implementing them at the application layer, but postponing making
> > the *default* behaviour configurable that way.
>
> I'm against any additional environment variables and command-line
> options. It will only complicate and obscure the security parameters of
> certi
isn't good yet (the cert is self-signed and replacing it
isn't trivial when it is even possible; and, because the self-signed cert
happens by default....it gets left in place). And in the case of those
embedded certs, the cert can wind up *invalid* (expired) as well as
self-signed. (This las
w* it is implemented as long as I don't have to touch the
code of a third party application when I upgrade my python version to
3.5...remember, the context here is backward compatibility concerns).
Does it address the issue of accepting an invalid cert, though?
--David
___
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
stematize and document that, and I
think that's a good idea.
We've been consistently treating lack of handling of EINTR as a bug.
If there are *real* cases where that causes a backward compatibility
problem, then we need to know. But so far, we have gotten zero
complaints about the cases that
On Mon, 01 Sep 2014 08:30:27 +0300, Marko Rauhamaa wrote:
> "R. David Murray" :
>
> > PS: I recently switched from using selectors to using a timeout on a
> > socket because in that particular application I could, and because
> > reading a socket with a timeo
On Mon, 01 Sep 2014 14:15:52 +0300, Marko Rauhamaa wrote:
> Charles-François Natali :
>
> >> Which raises an interesting question: what happens to the os.read()
> >> return value if SIGINT is received?
> >
> > There's no return value, a KeywordInterrupt exception is raised.
> > The PEP wouldn't
de in question will be (possibly vanishingly)
small, especially if you only consider python3. But we've already had
one call for a backport :)
--David
___
Python-Dev mailing list
Python-Dev@python.org
https://mail.python.org/mailman/listinfo/p
On Tue, 02 Sep 2014 20:59:54 -0400, Terry Reedy wrote:
> On 9/2/2014 7:47 PM, Glyph Lefkowitz wrote:
> >
> > On Sep 2, 2014, at 4:28 PM, Nick Coghlan > <mailto:ncogh...@gmail.com>> wrote:
> >
> >> On 3 Sep 2014 09:08, "David Reid" >&g
On Wed, 03 Sep 2014 16:31:13 +0200, Antoine Pitrou wrote:
> On Tue, 02 Sep 2014 21:29:16 -0400
> "R. David Murray" wrote:
> >
> > The top proposal so far is an sslcustomize.py file that could be used to
> > either decrease or increase the default securi
roku.com, but
in any case not some obscure little company...the actual cert was an
akamai cert, which means something is configured wrong somewhere.
--David
___
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
On Wed, 03 Sep 2014 10:09:36 -0700, Ethan Furman wrote:
> On 09/03/2014 08:58 AM, R. David Murray wrote:
> >
> > I'm OK with letting go of this invalid-cert issue myself, given the lack
> > of negative feedback Twisted got. I'll just keep my fingers crossed.
&g
ython.org/issue12067 and contribute
your thoughts there. There are indeed documentation improvements
under discussion.
--David
___
Python-Dev mailing list
Python-Dev@python.org
https://mail.python.org/mailman/listinfo/python-dev
Unsubscrib
small
> discrepancy in behaviour.
That would totally break the email package.
It would of course be possible to rewrite email to not use surrogate
escape, but it is a seriously non-trivial undertaking.
--David
___
Python-Dev mailing list
Python
email APIs as surrogateescape
encoded text; though, in practice, this being consenting-adults Python
and code not being bug free, there are places where people have used the
knowledge of how surrogateescape is used by email to work around both
API and code bugs.
--David
[*] Some of the encoded
On Wed, 17 Sep 2014 01:27:44 +1000, Chris Angelico wrote:
> On Wed, Sep 17, 2014 at 1:00 AM, R. David Murray
> wrote:
> > That isn't the case in the email package. The smuggled bytes are not
> > errors[*], they are literally smuggled bytes.
>
> But they
On Wed, 17 Sep 2014 04:02:11 +1000, Chris Angelico wrote:
> On Wed, Sep 17, 2014 at 3:46 AM, R. David Murray
> wrote:
> >> You can't treat them as characters, so while you have them in your
> >> string, you can't treat it as a pure Unicode string - it'
them either, so
> you will be somewhat vulnerable to bugs due to treating them as
> characters. But the same is true for CPython, AFAIK.
>From my point of view, the string function laxness is a feature, not a
bug. But I get what you mean.
--David
On Wed, 17 Sep 2014 14:42:56 +1000, Steven D'Aprano wrote:
> On Wed, Sep 17, 2014 at 11:14:15AM +1000, Chris Angelico wrote:
> > On Wed, Sep 17, 2014 at 5:29 AM, R. David Murray
> > wrote:
>
> > > Basically, we are pretending that the each smuggled
> >
Sorry for the mojibake. I've not yet gotten around to actually using
the email package to write a smarter replacement for nmh, which is what
I use for email, and I always forget that I need to manually tell nmh
when there non-ascii in the message...
On Wed, 17 Sep 2014 03:02:33 -0400, &quo
ire python3, I don't think there is a
solution and we're just going to have to cross that further bridge when
we come to it.
--David
___
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
ional help! I don't know that they have a formal task
list, but they might. (Although I also do sysadmin stuff, I've confined
myself to bugs.python.org for my python sysadmin work...and that isn't
currently handled by the python-infrastructure team).
--David
__
o the messages it is easy enough to
back out, but personally I find the new error messages *much* clearer, and I'm
an experienced dev.
(This work was done by Ezio Melotti, but I committed the final patch as
part of my quest to clear the 'commit review' queue in the tracker.)
--David
[
uld apply to python3 as apply to python2,
especially since more distros are about to start shipping python3 as
the system python (Arch has been since 2011).
3.1, however, is most likely a dead issue.
--David
___
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
s imaplib.
If it makes sense to implement it as a codec, there is no reason *not*
to do that.
--David
___
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
email address (and can't contain non-ASCII yet...we need RFC 6855
support for that, and I'm not sure *anybody* has that yet).
In this context it is the names you give to folders on the IMAP
server...starting (usually) with INBOX and adding from there. These
names are used in IMAP comm
On Fri, 10 Oct 2014 16:16:24 +0900, "Stephen J. Turnbull"
wrote:
> R. David Murray writes:
>
> > in the email address (and can't contain non-ASCII yet...we need RFC 6855
> > support for that, and I'm not sure *anybody* has that yet).
>
> If it'
hen the buildbot is red. I don't know if buildbot
supports that or not, so that would be the first thing to check.
--David
___
Python-Dev mailing list
Python-Dev@python.org
https://mail.python.org/mailman/listinfo/python-dev
Unsubscribe:
https://ma
romote someone to do it themselves. Even if we never
decide to support compiling CPython itself with MinGW, I would hope that
getting it to work for extensions would greatly reduce the number of
patches needed to be maintained outside the tree in order to do so. And
once at least one MinGW advo
ot get instant agreement on that (well, clearly you won't), but
it'd be much more likely you'd start garnering support.
Assume that people are well intentioned, and convince them your
suggestions will make things *even better* using positive arguments.
You might not succeed, but you'
MO.
Note: it can be made even less compelling by making it a lot easier to
build CPython on Windows without having an MSVC license (which I think
means not using the GUI, for which I say *yay* :). I think Zach Ware
has been working on improving the Windows build process, and I keep
meaning to give
ces any
easier to deal with :(
But as has been discussed, it seems better to focus first on fixing the
issues on which we are all in agreement (building extensions with MinGW).
> R. David Murray:
> > And, at this point, we would NEED A BUILDBOT. That is, a machine that
> > has
ut, people who develop Python software that *also* works on
Windows.
If you are writing code targeted for Windows, I think you are very
likely to have an MSDN subscription of some sort if your package includes C
code. I'm sure it's not 100%, though.
--David
___
e as one foundation the bash shell, taught on Windows via
git-bash. That is, the common toolset being taught to scientists (by
Software Carpentry) is the posix one, even on Windows.
--David
___
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
e process for the only non-trivial scenario
> > (64-bit Python 3.3/3.4 with free tools). But if people think it would
> > help, that's fine, I volunteer.
>
> The devguide needs to be kept up to date. If you open a tracker issue,
> put me as nosy to review and commit.
The
See issue 22766 for some background on this question.
On Mon, 03 Nov 2014 02:30:53 -0800, Ethan Furman wrote:
> Just to be clear, this is about NotImplemented, not NotImplementedError.
>
> tl;dr When a binary operation fails, should an exception be raised or
> NotImplemented returned?
>
>
>
ary operator methods should
> return NotImplemented when the types are incompatible.
Ethan opened an issue and then changed those docs, but I now believe
that the docs should be changed back (see the discussion in issue
22766).
--David
___
Python-Dev
Adding special case checks
should in general only be done if the resulting error message is
otherwise really confusing, which is not the case here.
As I said on the issue, there is no reason I can see to add extra code
just to turn an AttributeError into a TypeError. The AttributeError
works jus
just get lost here.
I'm doubtful this is a Python problem though. More likely it is an
issue with the curses library on OSX.
--David
___
Python-Dev mailing list
Python-Dev@python.org
https://mail.python.org/mailman/listinfo/python-dev
Unsub
of the few
putting any time in on tracker maintenance (not that I have much lately,
Ezio has done most of it) and I've still got the email docs to finish up
as well as a list of bugs...yeah, bandwidth is a problem.
But maybe I can take over coordination of the volunteers that want to
work on the fo
urious about These useful extension. Can you elaborate?
--
Pierre-Yves David
___
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
phases` for details.
--
Pierre-Yves David
___
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
system (http://unity3d.com/) using
Mercurial on windows.
We also have full featured GUI client http://tortoisehg.bitbucket.org/.
It is actively developed by people who stay in touch with the Mercurial
upstream so new feature tend to land in the GUI really fast.
--
Pierr
that if you
actually own the said interface. Because propriétary plateform are not
going to let your run arbitrary code on their machine.
--
Pierre-Yves David
___
Python-Dev mailing list
Python-Dev@python.org
https://mail.python.org/mailman/listinfo/pytho
e argument, they would been
currently writing Java code instead of discussing Python on this list.
--
Pierre-Yves David
___
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
printing at Pycon 2015. We can
probably arrange some workflow discussion//training there.
--
Pierre-Yves David
___
Python-Dev mailing list
Python-Dev@python.org
https://mail.python.org/mailman/listinfo/python-dev
Unsubscribe:
https://mail.python.org/mail
ting the DVCS content is usually easy. The hard part is then to
find all the script, tools, doc that rely on the previous tools to
upgrade them to the new one, sometimes trying to find feature parity.
This is rarely cheap and never "predictable"
oving to git and github send a very different signal: If you
want to be a successful command line tool, use C and bash. If you want
to be a successful website use ruby on rails.
--
Pierre-Yves David
[1] This is a personal statement is not to be linked to the opinion of
my employer PR department.
g to takes in account.
And is we simplify the technical debate (and shut it down as requested)
by saying both are equivalent. This is part of the other consideration
to take in account.
--
Pierre-Yves David
___
Python-Dev mailing list
Python-Dev@
. Could be worth poking at them to have and idea of what
is the status of it.
--
Pierre-Yves David
___
Python-Dev mailing list
Python-Dev@python.org
https://mail.python.org/mailman/listinfo/python-dev
Unsubscribe:
https://mail.python.org/mailman/options
sorted so quickly!" A perfect example is that R. David
> > Murray came up with a nice update for our workflow after PyCon but then ran
> > out of time after mostly defining it and nothing ever became of it (maybe we
> > can rectify that at PyCon?). Eric Snow has pointed out
On Sat, 06 Dec 2014 15:21:46 +, Brett Cannon wrote:
> On Sat Dec 06 2014 at 10:07:50 AM Donald Stufft wrote:
> > On Dec 6, 2014, at 9:11 AM, Brett Cannon wrote:
> >
> >> On Fri Dec 05 2014 at 8:31:27 PM R. David Murray
> >> wrote:
> >>> T
n contributions (like we do with Roundup).
> I know that there were times in the (not-so-recent) past when I had
> time and willingness to help with some part of the infrastructure, but
> didn't know where the code was, and didn't feel right making a blind
> offer.
Yeah, that&#x
y maintainers than they are for application
maintainers. Most of my work is in (customer) applications, and except
for one customer who insists on using an old version of RedHat, I've
been on "latest" python3 for those for quite a while now. I suspect we
hear less her
ge. Any performance benefit is actually a side effect of that
change. One that was considered, yes, but in the context of the
*language* as a whole and not any individual program's performance
profile. And "this doesn't make things worse for real world programs as
far as we can me
ets bogged down in differing opinions. (I
haven't myself looked at your proposals since I don't use
multiprocessing, so I don't know how radical the proposed changes are).
--David
___
Python-Dev mailing list
Python-Dev@python.org
https://m
On Mon, 12 Jan 2015 17:26:43 +, Steve Dower
wrote:
> David Anthoff wrote:
> > Yes, those are good examples. Right now doing this in the way these guys do
> > is
> > too much work for our small project... Anything that makes this easier
> > would be
> >
t missed it).
>
> Depending on "readily searchable", this isn't too bad:
>
> http://markmail.org/search/?q=list%3Aorg.python.python-dev+integer+docstring
But, if you are searching to see if a bug has been reported, you want to
search the tracker at
a reference somewhere I can read?
It is explained in the Sphinx documentation:
http://sphinx-doc.org/contents.html
Specifically:
http://sphinx-doc.org/markup/misc.html#directive-index
--David
___
Python-Dev mailing list
Python-Dev@python.org
https://ma
On Sun, 25 Jan 2015 14:00:57 +1000, Nick Coghlan wrote:
> It's far more developer friendly to aim to have builds from a source
> check-out "just work" if we can. That's pretty much where we are today
> (getting external dependencies for the optional parts on *nix can still be
> a bit fiddly - it m
hension:
> >
> > [*x for x in it]
> >
> > If `it` were a list of three items, this would be the same as
> >
> > [*it[0], *it[1], *it[2]]
>
> I find all this unreadable and difficult to understand.
I did too, before reading the PEP.
After reading t
On Mon, 26 Jan 2015 09:43:26 -0500, Barry Warsaw wrote:
> On Jan 25, 2015, at 09:31 PM, R. David Murray wrote:
>
> >> > > {*x for x in it}
> >> > >
> >> > > which is a set comprehension, while the other is a dict comprehension
> >> &g
I have run into situations like this elsewhere as well, but
this is the one from one of my current projects.
That said, I must admit to being a bit ambivalent about this, since
we otherwise are careful to disallow duplicate argument names.
So, instead we could write:
my_config_object.load(**{**defa
On Tue, 27 Jan 2015 00:07:08 +0100, Antoine Pitrou wrote:
> On Mon, 26 Jan 2015 16:28:24 -0500
> "R. David Murray" wrote:
> >
> > My use case is a configuration method that takes keyword parameters.
> > In tests I want to specify a bunch of default values for
ings are likely to stay unless/until he also gets himself banned
from the core workflow list.
Without emitting any judgment on your decision, I'm deeply sad that this
list have been "abandoned".
--
Pierre-Yves David
___
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
uotes makes me think it is looking for the literal string 'int', but
found the literal string 'str', whereas in the first case it seems
clear it is looking for objects of that type. Perhaps this is just
because I am used to the existing messages, but I think it goes
beyond th
's a
> known workaround.
Most likely you just need to run 'make touch' so that it doesn't try
to rebuild stuff it doesn't need to (because we check in those
particular build artifacts, like the frozen importlib).
--David
___
Issues counts and deltas:
> open4792 (-31)
> closed 30957 (+113)
> total 35749 (+82)
That's a successful sprint week :)
Thanks everyone!
--David
___
Python-Dev mailing list
Python-Dev@python.org
https://mail.python.org/mailman/l
ly reasonable to put the burden of making them useful onto the
linters/IDEs. The UI for it can unify the two files into a single
view...I know because way back in the dark ages I wrote a small
editor-based IDE that did something very analogous on an IBM Mainframe,
and it worked really well as a de
+1 to this from me too. I'm afraid that means I'm -1 on the PEP.
I didn't write this in my earlier email because I wasn't sure about it,
but my gut reaction after reading Harry's email was "if type annotations
are used in the stdlib, I'll probably stop contributing". That doesn't
mean that's *tru
gt; * Is open for reading
> * Etcetera
>
> That's not the type system's job. Not in Python. Maybe in Haskell, but
Just a note that if I'm reading the high level description right,
this kind of analysis is exactly the kind of thing that Flow does
for javascript.
make the reaction any less real, and the fact
that such reactions exist is a data point you should consider in
conducting your PR campaign for this issue. (I don't mean that last as
a negative: this issue *requires* an honest PR campaign.)
--David
___
_want_ to use
> are available and accepted. That'll be a developer workflow thing we could
> address with a later PEP. IF it happens at all.
This is the most reassuring statement I've heard so far ;)
--David
___
Python-Dev maili
On Tue, 21 Apr 2015 10:10:06 -0700, Guido van Rossum wrote:
> On Tue, Apr 21, 2015 at 9:17 AM, R. David Murray
> wrote:
>
> > Please be respectful rather than inflammatory. If you read what I
> > wrote, I did not say that I was going to stop contributing, I
> > spe
; tone of
(some) of the proponents (which makes us think this is going to get
pushed on us willy-nilly), whereas hearing a consistent message that
"this will *enable* interested parties to collaborate on type checking
without impacting the way the rest of you cod
I agree with Steve. There is *cognitive* overhead to type annotations.
I find that they make Python code harder to read and understand. So I
object to them in the documentation and docstrings as well. (Note:
while I agree that the notation is compact for the simple types, the
fact that it would
On Tue, 26 May 2015 08:20:01 +0200, Victor Stinner
wrote:
> What is wrong with "except:" in this specific case?
Nothing is wrong with it from a technical standpoint. However, if we
use 'except BaseException' that makes it clear that someone has thought
about it and decided that all exceptions s
nk we should look into getting speed.python.org up and
> > running for both Python 2 and 3 branches:
> >
> > https://speed.python.org/
> >
> > What would it take to make that happen ?
>
> I guess ideal would be some cooperation from some of the cpython devs
> > we don't have any way of reliably and reproducibly testing Python
> > performance.
> >
> > I'm very interested in speed.python.org and feel regret that the project is
> > standing still. I have a mind to contribute something ...
>
> On 03.06.2015 18:
901 - 1000 of 2106 matches
Mail list logo
