> Nick.
> >
> >>
> >> Paul
> >
> >
> >
> > --
> > Nick Coghlan | ncogh...@gmail.com | Brisbane, Australia
>
> FWIW It’s been David Cournapeau’s opinion (on Twitter at least) that
> some/all/most
> (I’m not sure exactly whi
e odd man
out. If it allowed list-of-bytes like python2/win32 and python2+3/unix
then this wouldn't be an issue.
Is this an actual problem, or is it something that should be handled
by application-level code as I've done?
Thanks,
--
David
___
Py
On Sun, Apr 20, 2014 at 2:42 AM, Antoine Pitrou wrote:
> On Sat, 19 Apr 2014 19:02:42 -0700
> David Aguilar wrote:
>>
>> On python3, this still works for normal platforms, but on windows we
>> can't pass a list of byte strings. We have to pass a list of unicode
&
e running under administrative
accounts, but not the literal Administrator account. Though I'm
guessing this topic may be moot for the XP slave as it doesn't have
UAC.
Claudiu, if you've got any specific test code you'd like to have
executed on either of my slaves to see
On Wed, Jul 4, 2018 at 3:02 AM Chris Angelico wrote:
> "Assignment is a statement" -- that's exactly the point under discussion.
> "del is a statement" -- yes, granted
> "function and class declarations are statements" -- class, yes, but
> you have "def" and "lambda" as statement and expression e
ldn't actually use.
On Wed, Jul 4, 2018 at 9:58 AM Chris Angelico wrote:
> On Wed, Jul 4, 2018 at 11:52 PM, David Mertz wrote:
> > On Wed, Jul 4, 2018 at 3:02 AM Chris Angelico wrote:
> >>
> >> "Assignment is a statement" -- that's exactly the
On Wed, Jul 4, 2018 at 12:13 PM Steven D'Aprano wrote:
> On Wed, Jul 04, 2018 at 10:20:35AM -0400, David Mertz wrote:
> > Hmmm... I admit I didn't expect quite this behavior. I'm don't actually
> > understand why it's doing what it does.
> >
> >
On Thu, Jul 5, 2018, 7:46 PM Alexander Belopolsky <
alexander.belopol...@gmail.com> wrote:
> It also appears that there are no cases where = can be substituted for :=
> and not cause a syntax error. This means that ":" in ":=" is strictly
> redundant.
>
Under your proposal, this is ambiguous: '
The case I find more reasonable is assignment in earlier arguments:
z = something ()
w = myfun(x := get_data(), y=calculate(x, z))
I would probably recommend against that in code review, but it's not
absurdly obfuscated.
On Sun, Jul 8, 2018, 1:15 PM Giampaolo Rodola' wrote:
>
>
> On Sun, Jul 8
On Thu, Jul 12, 2018, 1:24 PM Barry Warsaw wrote:
> It’s not the first time I’ve found myself in this position with a new
> Python feature, and it’s one of the reasons I deeply trust Guido’s
> intuition and sensibilities.
>
Sure... Except for the terrible choice to drop the '<>' inequality
opera
I've pretty much always taught using the "comprehension" term. It makes
sense to introduce comprehensions on concrete collections first. Then I
typically say something like "This special kind of comprehension is called
a 'generator expression'". Usually that's accompanied by a motivation like
creat
haps some of the newer pty changes I read Microsoft is making might
help, assuming it flows through to the isatty() test.
-- 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
The new postponed annotations have an unexpected interaction with
dataclasses. Namely, you cannot get the type hints of any of the data
classes methods.
For example, I have some code that inspects the type parameters of a
class's `__init__` method. (The real use case is to provide a default
serial
On Sat, Sep 22, 2018 at 3:11 PM Guido van Rossum wrote:
> Still, I wonder if there's a tweak possible of the globals and locals
used when exec()'ing the function definitions in dataclasses.py, so that
get_type_hints() gets the right globals for this use case.
On Sat, Sep 22, 2018 at 4:38 PM Yury
On Sat, Sep 22, 2018 at 12:41 PM Guido van Rossum
wrote:
> Probably a bugs.python.org issue is a better place to dive into the
details than python-dev.
Issue tracker issue created: https://bugs.python.org/issue34776
___
Python-Dev mailing list
Python-De
7; | cut -d"=" -f3" % (fs)*
It’s probably because you have “ characters that are inside “ characters and it
can’t tell where the string ends. It looks like you are trying to do
cmd = "blkid -o export %s | grep 'TYPE' | cut -d” = " -f3"
+1 to Brett's idea. It's hard to have a good mental model already of which
compression algorithms are and are not in stdlib. A package to contain them
all would help a lot.
On Wed, Nov 28, 2018, 12:56 PM Brett Cannon Are we getting to the point that we want a compresslib like hashlib if we
> are
On Thu, Nov 29, 2018, 2:55 PM Paul Moore ... and some users need a single, unambiguous choice for the
> "official, complete" distribution. Which need the current stdlib
> serves extremely well.
>
Except it doesn't. At least not for a large swatch of users.
10 years ago, what I wanted in Python w
voters wish to elect me.
Thanks, David Mertz...
--
Keeping medicines from the bloodstreams of the sick; food
from the bellies of the hungry; books from the hands of the
uneducated; technology from the underdeveloped; and putting
advocates of freedom in prisons. Intellectual property is
to t
of most core
developers. Not to say I have *no* instinct about those other questions,
but I know to defer.
Best, David...
> (*) (or Committee, I don't remember :-)
> David may of course provide an answer for himself, but allow me to
> provide my answer (and this is why I pushed for
On Fri, Jan 18, 2019, 5:55 AM Antoine Pitrou
> > id() returning the address of the object should be a guaranteed feature
>
> For me, the definitive answer is "yes, it's a CPython feature".
> That doesn't mean the CPython feature has to live forever. We may want
> to deprecate it at some point
W
sun.
On Fri, Jan 18, 2019 at 10:29 AM David Mertz wrote:
> On Fri, Jan 18, 2019, 5:55 AM Antoine Pitrou
>>
>> > id() returning the address of the object should be a guaranteed feature
>>
>> For me, the definitive answer is "yes, it's a CPython feature&qu
Ditto +1 option 4
On Wed, Jan 30, 2019, 5:56 PM Paul Moore On Wed, 30 Jan 2019 at 22:35, Raymond Hettinger
> wrote:
> > My recommendation is Option 4 as being less disruptive and more
> beneficial than the other options. In the unlikely event that anyone is
> currently depending on the reorderi
Hi everyone, I added a PR to add a sub-class of unittest.TestCase that makes it
possible to write async test methods. I wrote this a few months ago and it is
waiting on core review. Is there a core dev that can take up this review? I
would love to have this functionality in the core.
Lukasz
Parrot got rather further along than rattlesnake as a register based VM. I
don't think it every really beat CPython in speed though.
http://parrot.org/
On Mon, Mar 11, 2019, 5:57 PM Neil Schemenauer
wrote:
> On 2019-02-27, Victor Stinner wrote:
> > The compiler begins with using static single a
In my opinion, any test that relied on a non-promised accident of
serialization is broken today. Very often, such bad tests mask bad
production code that makes the same unsafe assumptions.
This is similar to tests that assumed a certain dictionary order, before we
got guaranteed insertion order. O
On Sun, May 26, 2019 at 11:17 PM Steven D'Aprano
wrote:
> > Nobody reads warnings.
>
> If nobody reads warnings, we should just remove the warnings module and
> be done with it. That should probably be a PEP.
>
We'll have to start issuing a PendingDeprecationWarning when folk import
the `warning
The old URL is definitely a lot friendlier, even apart from the length. I
know at a glance the month and list where the thread occurred, which is
perhaps the most important metadata. In the new link I only know what
mailing list it happened on, and nothing else meaningful.
On Thu, Jun 6, 2019, 8:2
This change would break two lovely functions I wrote this week.
On Thu, Jun 20, 2019, 12:35 PM Steve Dower wrote:
> On 20Jun2019 0205, Inada Naoki wrote:
> > Hi, all.
> >
> > Both of PyUnicdoe_FromString() and _Py_Identifier are
> > supporting UTF-8 for now. We can not change PyUnicode_FromStri
Ok. Good point. I used Unicode identifiers in my own project, not in
CPython. Some Greek letters that represent common mathematical concepts.
On Thu, Jun 20, 2019, 11:27 PM Inada Naoki wrote:
> On Fri, Jun 21, 2019 at 6:55 AM David Mertz wrote:
> >
> > This change would b
I agree with Greg.
There are various possible behaviors that might make sense, but having
`d.values() != d.values()` is about the only one I can see no sense in.
This really feels like a good cade for reading a descriptive exception. If
someone wants too compare `set(d.values())` that's great. If
Cliffe via Python-Dev <
python-dev@python.org> wrote:
>
>
> On 25/07/2019 00:09:37, David Mertz wrote:
> > I agree with Greg.
> >
> > There are various possible behaviors that might make sense, but having
> > `d.values() != d.values()` is about the only one I
On Thu, Jul 25, 2019 at 4:35 AM Petr Viktorin wrote:
> It's not the equality operator that errors: `==` means element-wise
> comparison in Numpy. The error would come from a conversion of the array
> to bool:
>
> >>> numpy.array([1, 2, 3]) == numpy.array([1, 3, 4])
> array([ True, False, False])
On Fri, Jul 26, 2019, 8:02 AM Greg Ewing
wrote:
> David Mertz wrote:
> >
> > We COULD do that with
> > `d1.values() == d2.values()` in principle. This "DictValuesComparison"
> > object could have methods like `.equal_as_set()` and
> > `.equal_as_list()`. H
I have read a great deal of discussion on the pattern matching PEPs and
less formal discussions. It is possible I have overlooked some post in all
of that, of course.
... OK, just saw Guido's "wait for new SC" comment, which I suppose applies
to this too :-).
One idea that I cannot recall seeing
Complimentary != Complementary
On Sun, Nov 15, 2020, 4:51 AM Paul Sokolovsky wrote:
> Hello,
>
> As was mentioned many times on the list, PEP634-PEP636 are thoroughly
> prepared and good materials, many thanks to their authors. PEP635
> "Motivation and Rationale" (https://www.python.org/dev/peps
On Sat, Nov 21, 2020 at 12:23 PM Steven D'Aprano
wrote:
> Clearly Spam(a=1, b=2) does not necessarily result in an instance with
> attributes a and b. But the pattern `Spam(a=1, b=2)` is intended to be
> equivalent to (roughly):
>
> if (instance(obj, Spam)
> and getattr(obj, a) == 1
>
o, really use this name as a value!" I like a word
better, but none of the current keywords really make sense, so it would
need to be a new word. I suggested "value", but another word might be
better.
On Thu, Nov 12, 2020 at 7:38 PM David Mertz wrote:
> One idea that I can
On Sat, Nov 21, 2020 at 2:47 PM Guido van Rossum wrote:
> On Sat, Nov 21, 2020 at 9:52 AM David Mertz wrote:
>
>> So in my mind, if I had the choice, it is a decision between a sigil and
>> a word to indicate "no, really use this name as a value!" I like a wor
On Mon, Nov 23, 2020, 2:58 PM Ethan Furman
> >> if isinstance(node, StringNode):
> >> return node.value
> >> elif isinstance(node, NumberNode):
> >> return float(node.value)
> >> elif isinstance(node, ListNode):
> >> return [p
I have a little bit of skepticism about the pattern matching syntax, for
similar reasons to those Larry expresses, and that Steve Dower mentioned on
Discourse.
Basically, I agree matching/destructuring is a powerful idea. But I also
wonder how much genuinely better it is than a library that does
On Mon, Nov 23, 2020 at 9:02 PM Brian Coleman
wrote:
> > Basically, I agree matching/destructuring is a powerful idea. But I also
> > wonder how much genuinely better it is than a library that does not
> require
> > a language change. For example, I could create a library to allow this:
>
>
On Mon, Nov 23, 2020, 4:32 PM Eric V. Smith
> I just commented on Steve's post over on Discourse. The problem with this
> is that the called function (m.case, here) needs to have access to the
> caller's namespace in order to resolve the expressions, such as StringNode
> and PairNone. This is one
>
> I'd put the question this way: assuming Matcher can be written (with a bit
> of stack magic), and assuming that the strings inside m.case() calls are
> exactly the same mini-languague PEP 634 proposes, would you want a syntax
> change?
>
> No, I wouldn't!
>
Is one of us mixing up negations? Are
Are there any filesystems that can actually record a meaningful ns
modification time? I find discussions claiming this:
- XFS and EXT3: second precision
- EXT4: millisecond precision
- NTFS: 100ns precision
- APFS: 1 ns precision
But also notes that the precision is likely to exceed the accuracy
As a candidate for the new SC, if elected I would certainly find it more
useful to have more specific thoughts from the outgoing SC than simply "we
recommend." How divided was the vote? Who took the sides? What were the
major points of disagreement? That sort of thing.
On Tue, Dec 8, 2020 at 9:39
On Tue, Dec 22, 2020 at 6:57 PM Alan G. Isaac wrote:
> The following test fails because because `seq1 == seq2` returns a
> (boolean) NumPy array
> whenever either seq is a NumPy array.
>
> import unittest
> import numpy as np
> unittest.TestCase().assertSequenceEqual([1.,2.,3.],
>
On Tue, Dec 22, 2020 at 11:44 PM Alan G. Isaac wrote:
> My question is not about work arounds.
> It is about whether the current definition of a sequence
> (in collections.abc) should govern `assertSequenceEqual`.
>
Why do you think a NumPy array is a sequence?
E.g.:
>>> a
array([[1, 2],
On Sun, Feb 14, 2021, 2:53 PM Gregory P. Smith wrote:
> *TL;DR of my TL;DR* - Not conveying bool-ness directly in the return
> annotation is my only complaint. A BoolTypeGuard spelling would
> alleviate that.
>
This is exactly my feeling as well. In fact, I do not understand why it
cannot simpl
On Sun, Feb 14, 2021, 5:34 PM Guido van Rossum wrote:
> But note that 'bool' in Python is not subclassable.
>
Sure. But that's why I suggested 'Bool' rather than 'bool'. It's a
different spelling, but one with a really obvious connection.
>
> I.e. if I read this:
>>
>> def is_str_list(v: List[A
Will someone publish an manylinux build to conda-forge (or their own
channel)?
On Thu, Feb 18, 2021 at 9:15 PM Dan Stromberg wrote:
>
> On Thu, Feb 18, 2021 at 12:02 AM Paul Sokolovsky
> wrote:
>
>> I think to resolve this issue to the completion, and avoid possibility
>> of an intermediary to
I've provided this excellent language interpreter as a conda package. For
users of conda, you can install it (on Linux) with:
conda install -c davidmertz python=0.9
(perhaps put it in a different environment than base).
I'm embarrassed by how much effort that took me. I used to teach
conda-
In conversation with Dan, I have fixed my conda package (but overwritten
the same version). I needed to add this to the build:
# sudo apt-get install gcc-multilib
CC='gcc -m32' make python
I don't have 32-bit headers by default anymore on my distro. With that
change, I can run:
% conda install
cular location) who would be willing to give me a review?
[1]: https://github.com/python/peps
[2]: https://github.com/python/peps/blob/master/README.rst
[3]: https://github.com/python/pythondotorg/pull/1735
--
David Foster | Seattle, WA, USA
Contributor to TypedDict support for
On Wed, Mar 10, 2021 at 1:13 PM Evpok Padding
wrote:
> Apparently renaming a git branch to follow the general convention is now
> an unbearable outrage. It strikes me as a somewhat odd hill to die on, but
> okay. However there is a code of conduct that is supposed to be followed
> here https://ww
On Wed, Mar 10, 2021, 4:30 PM Steven D'Aprano wrote:
> > All the other examples are also forced and contrived. This is perhaps
> worst. I own several chains for purposes having nothing to do with bondage
> or oppression.
>
> Chains are an almost universal symbol of bondage and slavery: "Man is
I feel like all of these examples, if found in the wild, are far more
likely to be uncaught bugs than programmer intent. Being strict about
spaces (or parents, brackets, etc. in other contexts) around numbers is
much more straightforward than a number of edge cases where is not obvious
what will ha
I recently encountered this, which is very useful, but only for a
human-readable perspective.
>>> import vaex
>>> vaex.__version__
{'vaex': '4.1.0', 'vaex-core': '4.1.0', 'vaex-viz': '0.5.0', 'vaex-hdf5':
'0.7.0', 'vaex-server': '0.4.0', 'vaex-astro': '0.8.0', 'vaex-jupyter':
'0.6.0', 'vaex-ml': '
arker
wrote:
> On Wed, Apr 14, 2021 at 7:48 AM David Mertz wrote:
>
>> >>> vaex.__version__
>> {'vaex': '4.1.0', 'vaex-core': '4.1.0', 'vaex-viz': '0.5.0', 'vaex-hdf5':
>> '0.7.0', '
On Wed, Apr 14, 2021 at 5:44 PM Christopher Barker
wrote:
> Another possible issue: using Version would require an extra import in
> many module initializations -- is that a performance issue that would
> matter?
>
I like having a `Version` object that is easily importable in the standard
librar
On Wed, Apr 14, 2021 at 9:12 PM Paul Moore wrote:
> If it's not basically equivalent to packaging.version.Version (and
> based on PEP 440) then we'll be creating a nightmare of confusion,
> because PEP 440 versions are fundamental to packaging.
>
Are you suggesting that users should have to inst
On Thu, Apr 15, 2021 at 4:55 PM Christopher Barker
wrote:
> Presumably that's why importlib.metadata exists in the stdlib.
>
I was so hopeful about this, but in the end... not really. I have not used
this capability before. Here are a few different situations I know of:
>>> import re, statist
On Thu, Apr 15, 2021 at 9:54 PM Christopher Barker
wrote:
> Or rather, the below is what I would find really nice to be able to do.
>
>> ver = robust_version(module)
>> if ver >= (5, 2, 1):
>> doit_modern_style()
>> elif ver < (5, 2, 1):
>> doit_old_style
>> else:
>> doit_unversioned_
I think what Christopher says is fair. My question (with little understanding
of the underlying infrastructure) is can we define a 'type' that communicates
that? Something like 'object that implements .read', or '.upper and .__iter__
for a spring-like object's?
toonarmycaptain
O
This reads like a much worse variation on GPT-3.
On Fri, Apr 23, 2021, 11:52 AM Pablo Galindo Salgado
wrote:
> I had I and still don't know what's going on. Mine was in a response to a
> release announcement so it was extra weird. Here is what I received:
>
> I have now formally filed a final la
A lot of times the present tense in changelogs and similar is the English
"historical present", also called "narrative present." When the verb comes
first, it is usually imperative, but these shade with context. E.g.
* Give class Froz a .bar() method
* Adding metaclass gives class Froz a .bar() me
On Thu, May 13, 2021 at 10:31 PM Christopher Barker
wrote:
> There was a discussion a while back ( a year or so?? ) on Python-ideas
> that introduced the idea of having more "sentinel-like" singletons in
> Python -- right now, we only have None.
>
As I remember, the year-ago conversation was bas
I think it's more future-looking to allow pickle round-tripping. Just add a
._uuid attribute and have object equality follow equality of that
attribute. There's no reason to expose that in the .__repr__, but it would
be inspectable in concept.
On Fri, May 14, 2021, 7:01 PM Irit Katriel via Python-
On Thu, May 20, 2021 at 6:21 AM Tal Einat wrote:
> On Sat, May 15, 2021 at 2:09 AM David Mertz wrote:
> > Just add a ._uuid attribute and have object equality follow equality of
> that attribute. There's no reason to expose that in the .__repr__, but it
> would be inspectab
On Thu, May 20, 2021, 2:11 PM Chris Angelico
> Probably the easiest way would be to have some kind of unique
> identifier (a fully-qualified name) that can be pickled, and then any
> time you attempt to construct a Sentinel with that identifier, it's
> guaranteed to return the same object.
Gosh,
On Thu, May 20, 2021 at 3:03 PM Ethan Furman wrote:
> > But it nevertheless feels like a bit of an abuse - the original point
> > of ellipsis was for indexing, and in particular complex slices like
> > a[1:20:2, ..., 3:5]. That usage is common in numpy, as I understand
> > it,
> Interesting -
813968
It would be pleasant if there were a way to make "cheap_sentinel" be the
same thing—either by equality or by identity—betweeen those two runs of the
interpreter.
None or Ellipsis have that property, of course. So do, for example,
integers, at least by equality if not identity (yes,
This is perhaps a different issue, but perhaps not. PSF grants are also
subject to absurd and convoluted (and difficult to interpret) "export
control" rules. Also rules subject to change at any moment at the whims of
the latest US government grandstanding.
USA incorporation definitely has drawback
>
> From: Eli Bendersky
>
> I'll be the first one to admit that pycparser is almost certainly not
> generally useful enough to be exposed in the stdlib. So just using it as an
> implementation detail is absolutely fine. PLY is a more interesting
> question, however, since PLY is somewhat more ge
. ?
In the scientific community, we have used the convention of making the
test suite available at runtime with pkgname.tests().
David
___
Python-Dev mailing list
Python-Dev@python.org
http://mail.python.org/mailman/listinfo/python-dev
Unsubscribe:
http://mail.python.org/mailman/options/python-dev/archive%40mail-archive.com
Recently I helped out on issue16954 which involved filling in docstrings
for methods and classes in ElementTree.py
While doing so, I tried to test my work in the interpreter like this...
>>> from xml.etree.ElementTree import Element
>>> help(Element)
...but found that help() showed nothi
On Fri, 2013-05-17 at 12:42 -0400, Barry Warsaw wrote:
> On May 16, 2013, at 04:52 PM, Terry Jan Reedy wrote:
>
> >If the corruption only happens on Ubuntu, that would constitute 'rhyme'
> >;-). I realize that asking for reports on other systems is part of the reason
> >you posted, but I don't rem
On Fri, 2013-05-17 at 14:23 -0400, Barry Warsaw wrote:
> On May 17, 2013, at 01:19 PM, David Malcolm wrote:
>
> >Fedora/RH pregenerate the .pyc files during rpm creation, and they exist
> >as part of the rpm payload.
>
> Good to know, thanks. Do you use `$PYTHON -m py_
On Mon, 2013-06-03 at 12:48 -0400, Barry Warsaw wrote:
> On Jun 03, 2013, at 09:05 AM, Ben Darnell wrote:
>
> >The data is analogous to the time zone database (PEP 431) in that it may
> >need to be updated independently of Python's own release schedule, so we
> >may want to use similar techniques
On Tue, 2013-06-11 at 12:14 -0700, Benjamin Peterson wrote:
> 2013/6/11 Skip Montanaro :
> > I encountered this disconcerting message yesterday on a Linux system
> > running Python 2.7.2:
> >
> > *** glibc detected *** /opt/local/bin/python: corrupted double-linked
> > list: 0x03b01c90 ***
on the buildbot machine, so it appears that
the timing of the failures and particular changesets is coincidental.
I've repaired the filesystem and the disk passes a surface scan, so
hopefully it'll be cleaned up. I've also re-queued the most recent builds
in each branch.
-- David
_
akes it an ideal candidate for
> >> standard library inclusion.
> >>
> >> Is this still on the table?
> >
> > Who is the maintainer and what is his opinion?
>
>
> The maintainer is David Beazley and as far as I recall he has not expressed
> an opinion on
On Jul 14, 2013, at 8:13 AM, Brett Cannon wrote:
>
>
>
> On Sun, Jul 14, 2013 at 2:54 AM, Nick Coghlan wrote:
> On 13 July 2013 23:26, David Beazley wrote:
> I'm in favor of PLY going into stdlib with the caveat that there are some
> things about it that should
On Mon, 2013-07-22 at 09:32 +0200, Maciej Fijalkowski wrote:
> On Mon, Jul 22, 2013 at 9:32 AM, Maciej Fijalkowski wrote:
> > On Mon, Jul 22, 2013 at 8:15 AM, Antoine Pitrou wrote:
> >> On Sun, 21 Jul 2013 16:36:35 -0700
> >> Raymond Hettinger wrote:
> >>> Our current Mac OS X builds use GCC-4.2
On Mon, 2013-07-22 at 17:15 +0200, Antoine Pitrou wrote:
> Le Mon, 22 Jul 2013 11:08:32 -0400,
> David Malcolm a écrit :
> >
> > How did this thread go from:
> > "for OS X, GCC 4.8.1 gives you significantly faster machine code
> >than the system GCC
on, Jul 22, 2013 at 12:09 PM, Ronald Oussoren wrote:
>
> On 22 Jul, 2013, at 17:08, David Malcolm wrote:
>
> > On Mon, 2013-07-22 at 09:32 +0200, Maciej Fijalkowski wrote:
> >> On Mon, Jul 22, 2013 at 9:32 AM, Maciej Fijalkowski
> wrote:
> >>> On Mon, Jul 22,
-dev
> Unsubscribe:
> http://mail.python.org/mailman/options/python-dev/dwightdhutto%40gmail.com
>
--
Best Regards,
David Hutto
*CEO:* *http://www.hitwebdevelopment.com*
___
Python-Dev mailing list
Python-Dev@python.org
http://mail.python.org/mailma
t code (which I can't control) wasn't very important.
2 hours had been conservative (and a trade-off as longer values also
risks failing more future tests) but it may need to be increased.
In this particular case it was a false alarm - the host was heavily
loaded during this time frame, wh
pository hgrc following a clone, or just prior to the update step.
-- David
___
Python-Dev mailing list
Python-Dev@python.org
http://mail.python.org/mailman/listinfo/python-dev
Unsubscribe:
http://mail.python.org/mailman/options/python-dev/archive%40mail-archive.com
On Fri, 2016-06-10 at 23:20 +1000, Steven D'Aprano wrote:
> On Fri, Jun 10, 2016 at 01:13:10PM +0200, Victor Stinner wrote:
> > Hi,
> >
> > Last weeks, I made researchs on how to get stable and reliable
> > benchmarks, especially for the corner case of microbenchmarks. The
> > first result is a se
This is fairly academic, since I do not anticipate needing to do this
myself, but I have a specific question. I'll assume that Python 3.5.2 will
go back to the 2.6-3.4 behavior in which os.urandom() never blocks on
Linux. Moreover, I understand that the case where the insecure bits might
be retur
On Fri, Jun 10, 2016 at 11:33 AM, Donald Stufft wrote:
>
> On Jun 10, 2016, at 2:29 PM, David Mertz wrote:
>
> If I *were* someone who needed to write a Linux system initialization
> script using Python 3.5.2, what would the code look like. I think for this
> use case, requiri
use of your application” behavior.
>
> So really, out of the recommended solutions you really only have find a
> way to interface with the getrandom() function, or just consume
> /dev/urandom and hope it’s been initialized.
>
>
> On Jun 10, 2016, at 2:43 PM, David Mertz wrote:
>
&g
I believe that secrets.token_bytes() and secrets.SystemRandom() should be
changed even for 3.5.1 to use getrandom() on Linux.
Thanks for fixing my spelling of the secrets API, Donald. :-)
On Fri, Jun 10, 2016 at 12:17 PM, Donald Stufft wrote:
>
> On Jun 10, 2016, at 3:05 PM, David Mertz
Ooops thinko there! Of course `secrets` won't exist in 3.5.1, so that's
a 3.6 matter instead.
On Fri, Jun 10, 2016 at 12:29 PM, David Mertz wrote:
> I believe that secrets.token_bytes() and secrets.SystemRandom() should be
> changed even for 3.5.1 to use getrandom() on Linux
On Fri, Jun 10, 2016 at 12:55 PM, Larry Hastings wrote:
> On 06/10/2016 12:29 PM, David Mertz wrote:
>
> I believe that secrets.token_bytes() and secrets.SystemRandom() should be
> changed even for 3.5.1 to use getrandom() on Linux.
>
> Surely you meant 3.5.2? 3.5.1 shi
On Thu, Jun 16, 2016 at 11:58 AM, Nathaniel Smith wrote:
> [...] no one else be able to predict what session cookie I sent [...] In
> python 2.3-3.5, the most correct way to write this code is to use
> os.urandom. The question in this thread is whether we should break that in
> 3.6, so that consc
on that someone
stick on Python 2.7 or 3.3 shouldn't be able to include the future-style:
import secrets
Answer = secrets.token_bytes(42)
On Jun 16, 2016 4:53 PM, "Nick Coghlan" wrote:
> On 16 June 2016 at 13:09, Barry Warsaw wrote:
> > On Jun 16, 2016, at 01:01 PM, David M
It seems unlikely, but not inconceivable, that someday in the future
someone will implement a dictionary that is faster than current versions
but at the cost of losing inherent ordering.
It feels best to me only to promise order in specific cases like kwargs,
but say nothing (even in 3.6 or 3.7) a
I'm forwarding this to the PSF Trademarks committee. If there is a
violation, it's a misuse of trademark, not copyright on the code which has
the Python license stack.
I'm on that committee and agree this is improper use. Let's see what other
members think.
On Dec 10, 2016 12:19 AM, "Barry Warsaw
101 - 200 of 1990 matches
Mail list logo
