do with code
> objects and bytecode (since we sometimes think of better ways to execute
> Python).
>
Perhaps "living API" analogous to "living document". Much more positive
connotations ...
Tim Delaney
___
Python-Dev mailing lis
On Wed, 20 Mar 2019 at 00:29, Serhiy Storchaka wrote:
> 19.03.19 15:10, Tim Delaney пише:
> > Now Calibre is definitely in the wrong here - it should be able to
> > import regardless of the order of attributes. But the fact is that there
> > are a lot of tools out there that
#x27;s getting
beyond the scope of this discussion.
Tim Delaney
___
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 top of a dict, but if you do use any reordering
operations, it adds in the additional heavyweight structure required to
support that?
I'm pretty sure something similar has been considered before, but thought I
should bring it up in the context of this discussion (if only to have to
shot
On 29 March 2018 at 08:09, Tim Delaney wrote:
> On 29 March 2018 at 07:39, Eric V. Smith wrote:
>
>> I’d vote #3 as well.
>>
>> > On Mar 28, 2018, at 11:27 AM, Serhiy Storchaka
>> wrote:
>> >
>> > There is a subtle semantic differenc
On 29 March 2018 at 07:39, Eric V. Smith wrote:
> I’d vote #3 as well.
>
> > On Mar 28, 2018, at 11:27 AM, Serhiy Storchaka
> wrote:
> >
> > There is a subtle semantic difference between str.format() and
> "equivalent" f-string.
> >
> >'{}{}'.format(a, b)
> >f'{a}{b}'
> >
> > In most cas
err,
which didn't exist and caused the program to hang.
However, I'm definitely +1 on enabling DeprecationWarning by default, but
with mechanisms or recommendations for the application developer to silence
them selectively for the current release.
Tim Delaney
__
< (3, 8):
with warnings.simplefilter('ignore', DeprecationWarning):
import module
The idea here is to prompt the developer to refactor to not use the
deprecated functionality early enough that users aren't impacted.
Tim Delaney
nsertion order" are fairly simple
to explain, "dicts maintain insertion order up to the point that a key is
deleted" is less so.
Tim Delaney
___
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 6 November 2017 at 07:50, Peter Ludemann via Python-Dev <
python-dev@python.org> wrote:
> Isn't ordered dict also useful for **kwargs?
>
**kwargs is already specified as insertion ordered as of Python 3.6.
https://www.python.org/dev/peps/pep-0
On 26 June 2017 at 08:20, Tim Delaney wrote:
>
> 2. Last I checked hggit can't force-push to a git repository after
> history-modifying actions (e.g. rebase) so after such actions it's
> necessary to delete any existing branch in a local git repo, hg push to
> that
g branch in a local git repo, hg push to
that then force-push to Github. This wnew branch head.
So the workflow I use for working with Github is (after enabling hggit):
git clone .git
hg clone git+.git
cd .hg
...
cd .git
git branch -d
cd .hg
hg push
can definitely find cases in my current java codebase where I've used the
pattern (LinkedHashSet) and the order is important to the semantics of the
code.
Tim Delaney
___
Python-Dev mailing list
Python-Dev@python.org
https://mail.python.org/mai
rom such
a dict implementation.
Personally I expect all Python 3.6 implementations will have
order-preserving dict as that's the easiest way to achieve the existing
guarantees. And that enough code will come to depend on an order-preserving
n, but is that a valid assumption? Guess I can test it now
3.6.0b1 is out.
Tim Delaney
___
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 9 September 2016 at 15:34, Benjamin Peterson wrote:
> On Thu, Sep 8, 2016, at 22:33, Tim Delaney wrote:
> > On 9 September 2016 at 07:45, Chris Angelico wrote:
> >
> > > On Fri, Sep 9, 2016 at 6:22 AM, Victor Stinner <
> victor.stin...@gmail.com>
> > &
t;
Are sets also ordered by default now? None of the PEPs appear to mention it.
Tim Delaney
___
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
entityHashMap
which may also need an ordered equivalent.
There is a repo for Jython 3.5 development:
https://github.com/jython/jython3 but it doesn't seem to be very active -
only 11 commits in the last year (OTOH that's also in the last 3 months).
Tim Delaney
pt doesn't even exist in Git.
I switched all of my development to Mercurial, and use hg-git and
hgsubversion when I need to interact with those systems.
Tim Delaney
___
Python-Dev mailing list
Python-Dev@python.org
https://mail.python.org/mailman/li
e(): return 'very'
> ...
> >>> f'f-strings are {how_awesome()} awesome!'
> 'f-strings are very awesome!'
>
> I'm open to any suggestions to improve the PEP. Thanks for your feedback.
>
I'd like to see an alternatives
results. I imagine that there might be significant differences
between solid state drives, hard drives and network mounts.
Tim Delaney
___
Python-Dev mailing list
Python-Dev@python.org
https://mail.python.org/mailman/listinfo/python-dev
Unsubscribe:
https://
On 14 July 2014 12:17, Nick Coghlan wrote:
>
> I think os.walk() is a good source of inspiration here: call the flag
> "followlink" and default it to False.
>
Actually, that's "followlinks", and I'd forgotten that os.walk() defaulted
to not follow -
o a parent directory);
3. Symlinks to non-existent files/directories;
4. Symlink to an absolutely huge directory somewhere else (very annoying if
you just wanted to do a directory sizer ...).
If follow_symlinks=False by default, only those who opt-in
he other way around.
>
For most uses the most natural thing is to follow symlinks (e.g. opening a
symlink in a text editor should open the target). However, I think not
following symlinks by default is better approach for exactly the reason
Paul has noted above.
Tim Delaney
___
x27;re
only dealing with directories, but symlinks work with files as well.
I work cross-platform, and have a mild preference for option #2 with
similar semantics on all platforms.
Tim Delaney
___
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 1 July 2014 08:38, Ethan Furman wrote:
> On 06/30/2014 03:07 PM, Tim Delaney wrote:
>
>> I'm torn between whether I'd prefer the stat fields to be populated
>> on Windows if ensure_lstat=False or not. There are good arguments each
>> way, but overa
. I think the best way to handle this is a
> .fullname or .full_name attribute as suggested elsewhere. Thoughts?
>
+1 for .fullname. The earlier suggestion to have __str__ return the name is
killed I think by the fact that .fullname could be bytes.
It would be nice if pathlib.Path obj
andir
Other than that:
+1 for adding scandir to the stdlib
-1 for windows_wildcard (it would be an attractive nuisance to write
windows-only code)
Tim Delaney
___
Python-Dev mailing list
Python-Dev@python.org
https://mail.python.org/mailman/listinfo
pt is dead simple.
If the MicroPython string type requires people *using* it to deal with
surrogates (i.e. indexing could return a value that is not a valid Unicode
code point) then it will have broken the conceptual simplicity of the
Python 3 string type (and most certainly can
you have that, everything is
layered on top of it. How the code points themselves are implemented is
opaque and irrelevant other than the memory and performance consequences of
the implementation decisions (for example, a string could be indexable by
iterating from the start until you find the nth c
maintains a string type that presents code points as indivisible
elements;
2. The performance consequences of using UTF-8 are documented, as well as
any optimisations, tricks, etc that are used to overcome those consequences
(and what impact if any they would have if code written for MicroPython was
ru
n the not to distant
future (Mercurial was rejected as a sponsor organisation - Giovanni
Gherdovich is liaising with the PSF about it).
Tim Delaney
___
Python-Dev mailing list
Python-Dev@python.org
https://mail.python.org/mailman/listinfo/python-dev
always return a
boolean.
If exception expressions already existed in the language, I would think
there would be a strong argument for a library function hasattr(), but
probably not a builtin.
Tim Delaney
___
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
; This version might be more readable:
>
>value = lst[2] except "No value" if IndexError
>
+1 - it's readable, clear, and only uses existing keywords.
Tim Delaney
___
Python-Dev mailing list
Python-Dev@python.org
https://mail.p
n't think "then" is a good fit (even if
it didn't add a keyword).
Unfortunately, I can't come up with anything better ...
Tim Delaney
___
Python-Dev mailing list
Python-Dev@python.org
https://mail.python.org/mailman/listinfo/pyt
I've just posted about PEP 460 and this discussion on the mercurial-devel
mailing list.
Tim Delaney
___
Python-Dev mailing list
Python-Dev@python.org
https://mail.python.org/mailman/listinfo/python-dev
Unsubscribe:
https://mail.python.org/ma
On 29 November 2013 13:17, Terry Reedy wrote:
> On 11/28/2013 7:06 PM, Tim Delaney wrote:
>
> By default in Win7 AppData is a hidden folder - you need to go to Tools
>>
>
> On my system, that is Control Panel, not Tools.
Sorry - was referring to the Explorer "Tool
, folders and drives to see it in
Explorer (no matter what user you're logged in as).
If the py.ini location does become defined in terms of %LOCALAPPDATA% then
suggesting to use that value in the Explorer address bar would probably be
the easiest way for people to get to the correct dire
On 29 November 2013 08:34, Glenn Linderman wrote:
> On 11/28/2013 1:04 PM, Tim Delaney wrote:
>
>
> %LOCALAPPDATA% should always contain the same value as would be returned
> from SHGetFolderPath with CSIDL_LOCAL_APPDATA.
>
> Except when it gets changed. Documentation shou
he current
user’s "application data" directory (i.e. the directory returned by
executing `echo %LOCALAPPDATA%` in a command window) and py.ini in the same
directory as the launcher.
%LOCALAPPDATA% should always contain the same value as would be returned
from SHGetFolderPath with CSIDL
oticed (eventually) unless the attacker also
compromised all those other machines.
Tim Delaney
___
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
could be bypassed
if you temporarily cached the result of this stat call? And if so, when
should the cached value be cleared?
Tim Delaney
___
Python-Dev mailing list
Python-Dev@python.org
https://mail.python.org/mailman/listinfo/python-dev
Unsubscribe:
h
xceptions = []
try:
os.unlink('missing.txt')
except OSError as exc:
exceptions.append(exc)
try:
os.unlink('missing.txt')
except OSError as exc:
exceptions.append(exc)
try:
os.unlink('missing.txt')
except OSError as exc:
exceptions.append(exc)
for ex
elopers having slow machines so they feel the pain ...
Tim Delaney
___
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 considered a craft, with pride in what we produced.
However, I think I should probably reconsider my viewpoint in light of my
current employment ... I despair at some of the code I see ...
Tim Delaney
___
Python-Dev mailing list
Python-Dev@python.org
ite
well for this - you can modify the resource constraints (CPU, memory, etc)
to simulate different scenarios.
I find that this tends to better promote the methodology of "make it right,
then make it fast (small, etc)", which I subscribe to. Optimising too
nicalDict, where the canonical key is defined to be the first key
inserted. It would in fact be possible (though inefficient) to implement
that using a canonicalising callable that maintained state - something like
(untested):
class OriginalKeys:
def __init__(self)::
On 13 September 2013 07:29, Tim Delaney wrote:
>
> In this case though, there are two pieces of information:
>
> 1. A canonical key (which may or may not equal the original key);
>
> 2. The original key.
>
> It seems to me then that TransformDict is a specialised case o
med keys (I'd call them canonical keys). That
way there's no question about which key is stored - it's *always* the
transformed key.
In fact, I think this might get more traction if it were referred to as a
canonicalising dictionary (bikeshedding, I know).
Tim Delaney
___
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
_merge.
I think it's a perfectly reasonable approach.
I expanded on it a little to make it more general (to choose which parent
to discard) in
http://stackoverflow.com/questions/14984793/mercurial-close-default-branch-and-replace-with-a-named-branch-as-new-default/14991454#149
On 7 May 2013 14:54, Ethan Furman wrote:
> On 05/06/2013 07:58 PM, Tim Delaney wrote:
>
>>
>> Considering that doesn't actually work with the reference implementation
>> (AutoNumber.__new__ is never called) ... no.
>>
>
> Two points:
>
>
On 7 May 2013 15:14, Tim Delaney wrote:
> Unfortunately, if you subclass AutoNumber from IntEnum it breaks.
>
> -- Run Python3 --
> Traceback (most recent call last):
> File "D:\home\repos\mercurial\ref435\ref435.py", line 346, in
> class Co
On 7 May 2013 15:14, Tim Delaney wrote:
> D'oh! I had my default path being my forked repo ... so didn't see the
> changes. BTW I can't see how that exact implementation passes ... not
> enough parameters declared in AutoNumber.__new__ ...
>
Sorry - my fault again
On 7 May 2013 12:29, Ethan Furman wrote:
> On 05/05/2013 02:55 PM, Tim Delaney wrote:
>
>>
>> So long as I can get one of the requirements documented to implement an
>> auto-number syntax I'll be happy enough with
>> stdlib enums I think.
>>
On 5 May 2013 21:58, Tim Delaney wrote:
> On 5 May 2013 16:17, Ethan Furman wrote:
>
>> On 05/04/2013 10:59 PM, Ethan Furman wrote:
>>
>>> On 05/04/2013 08:50 PM, Tim Delaney wrote:
>>>
>>>> 2. Instead of directly setting the _name and _value of
order, so I think making it easily available to enum metaclass
subclasses as well just makes sense.
Tim Delaney
___
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 6 May 2013 08:00, Guido van Rossum wrote:
> On Sun, May 5, 2013 at 2:55 PM, Tim Delaney
> wrote:
> > So long as I can get one of the requirements documented to implement an
> > auto-number syntax I'll be happy enough with stdlib enums I think.
>
> Specificall
;Duplicate enum key '%s.%s' (overriding '%s')" %
(result.__name__, v.key, k
eys[v.key]))
AttributeError: Duplicate enum key 'MoreColor.red' (overriding 'Color.red')
>>>
So long as I can get one of the requirements documented to implement an
aut
On 5 May 2013 16:17, Ethan Furman wrote:
> On 05/04/2013 10:59 PM, Ethan Furman wrote:
>
>> On 05/04/2013 08:50 PM, Tim Delaney wrote:
>>
>>> 2. Instead of directly setting the _name and _value of the enum_item, it
>>> lets the Enum class do it via Enum.__init
TestAutoIntEnum(AutoIntEnum):
a = ...
b = 3
c = ...
class TestAutoIntEnum2(AutoIntEnum):
a = ...
b = ...
c = ...
print(TestAutoIntEnum, list(TestAutoIntEnum))
print(TestAutoIntEnum2, list(TestAutoIntEnum2))
------ Run ---
On 5 May 2013 13:32, Ethan Furman wrote:
> On 05/04/2013 08:11 PM, Tim Delaney wrote:
>
>>
>> I've been able to achieve the auto-numbering without relying on the
>> internal implementation at all (with a
>> limitation), with a single change to enum_typ
On 5 May 2013 13:11, Tim Delaney wrote:
> @@ -142,6 +152,7 @@
> if obj_type in (object, Enum):
> enum_item = object.__new__(enum_class)
> else:
> +value = obj_type.__new__(obj_type, value)
>
On 5 May 2013 11:22, Tim Delaney wrote:
> On 5 May 2013 10:49, Eli Bendersky wrote:
>
>>
>> On Sat, May 4, 2013 at 4:27 PM, Tim Delaney
>> wrote:
>>
>>> Typo line 171:
>>>
>>>
>> Fixed, thanks.
>>
>>
>>
>>&
ributor Form Received" field is "No" in user
details, there be a link to http://www.python.org/psf/contrib/.
Tim Delaney
___
Python-Dev mailing list
Python-Dev@python.org
http://mail.python.org/mailman/listinfo/python-dev
Unsubscribe:
ht
On 5 May 2013 10:49, Eli Bendersky wrote:
>
> On Sat, May 4, 2013 at 4:27 PM, Tim Delaney
> wrote:
>
>> Typo line 171:
>>
>>
> Fixed, thanks.
>
>
>
>> One thing I'd like to be clear in the PEP about is whether enum_type and
>> _En
st(TestAutoNumber))
print(TestAutoInt, list(TestAutoInt))
-- Run ----------
[, ,
]
[, ,
]
Tim Delaney
___
Python-Dev mailing list
Python-Dev@python.org
http://mail.python.org/mailman/listinfo/python-dev
Unsubscribe:
http://mail.python.org/m
e people (in the above that Color.red is not an
instance of MoreColor), or is going to result in a contravariance violation.
Tim Delaney
___
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
jected the auto-numbering syntax a while back. The only case
> in which auto-numbering occurs (per PEP 435) is the "convenience syntax":
>
> Animal = Enum('Animal', 'fox dog cat')
>
Actually, since Guido has pronounced that definition order will be the
On 22 April 2013 10:31, Barry Warsaw wrote:
> On Apr 22, 2013, at 09:31 AM, Tim Delaney wrote:
>
> >I'm fine with iteration order being by sorted name by default, so long as
> >it's easily overrideable by enum subclasses or metaclasses e.g. an IntEnum
> >shou
der being by sorted name by default, so long as
it's easily overrideable by enum subclasses or metaclasses e.g. an IntEnum
should probably iterate in value order.
For definition order, a 3.x-only metaclass could be provided:
class Days(enum.Enum, metaclass=enum.
be unambiguous. If we have iteration in definition order, I'd say the
first defined name for a value should be the canonical name, and any other
name for the value should be considered an alias.
That would preclude the syntax above, but the following might be workable:
class Insect(Enum):
On 21 April 2013 04:10, Barry Warsaw wrote:
> On Apr 13, 2013, at 08:37 AM, Tim Delaney wrote:
>
> >Just using definition order as the stable iteration order would do the
> >trick - no need for any comparisons at all. Subclasses (e.g. IntEnum) can
> >then override it
lass that implemented comparisons defined
based on iteration order. It makes sense not to have this in the base Enum
class (it would be confusing).
On a related note, I really would like to have the ordinal exposed if this
were added.
Tim Delaney
___
P
one) or the type of the table in the existing dbf file.
>
I fall into:
1. int(), float(), str() etc should return that exact class (and
operator.index() should return exactly an int).
2. It could sometimes be useful for __int__() and __index__() to return a
subclass of int.
So, for
and all the hardlinks to the same file.
There's also a command-line version - ln <
http://schinagl.priv.at/nt/ln/ln.html>.
Highly recommended.
Tim Delaney
___
Python-Dev mailing list
Python-Dev@python.org
http://mail.python.org/mailman/list
ums int-based (and comparable with ints)
was because I read somewhere that Guido had said that any stdlib enum would
have to be an int subclass.
I have no problems with having int-like enums that:
1. Are not int subclasses;
2. Do not compare equal with ints unles
sn't have an ordinal at all (except
by accident in the trivial case). That was when I decided to put it aside
for a while and see where the discussion went.
Tim Delaney
___
Python-Dev mailing list
Python-Dev@python.org
http://mail.python.org/mailman/
Apologies the top-posting (damned Gmail ...).
Tim Delaney
___
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
each collapsed changeset is for a single change I
haven't seen this be a major issue. However, I'm personally a "create a new
named branch for each task, keep all intermediate history" kind of guy (and
I get to set the rules for my team ;) so I don't see collapsed changesets
leted from (probably most dict
literals) and it would be nice to have an iteration order for them that
matched the source code.
However if deletions occur all bets would be off. If you need to maintain
insertion order in the face of deletions, use an explicit ordereddict.
Tim Delaney
__
e Cython on
speed.python.orgeventually (in two modes - one without hints as a
baseline and one with
hints). Of course the ideal situation would be to have every implementation
of Python 3.3 that is capable of running on the hardware contributing
numbers e.g. if/when Jython achieves 3.3 compatibility
slightly higher).
To be clear - I'm *not* suggesting Cython become part of the required build
toolchain. But *if* the Cython-compiled extensions prove to be
significantly faster I'm thinking maybe it could become a semi-supported
option (e.g. a HOWTO with the caveat &
Also the example at
http://docs.python.org/py3k/whatsnew/3.3.html#pep-409-suppressing-exception-contextreads:
... raise AttributeError(attr) from None...
Looks like there's an elipsis there that shouldn't be.
Tim Delaney
___
BTW, "What's New": http://www.python.org/download/releases/3.3.0/ still
says 80x for decimal performance.
Tim Delaney
___
Python-Dev mailing list
Python-Dev@python.org
http://mail.python.org/mailman/listinfo/python-dev
Uns
On 29 September 2012 07:50, Tim Delaney wrote:
> On 29 September 2012 06:51, Paul Moore wrote:
>
>>
>> Wow! I had no idea cdecimal was that close in speed to float. That's
>> seriously impressive.
>>
>
> If those numbers are similar in other benchmarks,
On 29 September 2012 06:51, Paul Moore wrote:
>
> Wow! I had no idea cdecimal was that close in speed to float. That's
> seriously impressive.
>
If those numbers are similar in other benchmarks, would it be accurate
and/or reasonable to include a statement along the lines of:
"comparable to flo
ng weakrefs before GC -
however, since the object would then be completely unreachable (except by C
code) I'm not sure it matters.
Tim Delaney
___
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
27;s valid).
By choosing relative terms, it caters to people's desire to have the "best"
clock, but doesn't set the expectation that the behaviour is guaranteed.
Tim Delaney
___
Python-Dev mailing list
Python-Dev@python.org
http://ma
a slight cost compared to previously (always importing the python
version) and you'll still be using cElementTree directly until it's
removed, but if/when it is removed you won't notice it.
Tim Delaney
___
Python-Dev mailing list
Python-Dev@p
and __context__ alone, and if you're raising a *new*
> exception, then __cause__ will already be Ellipsis by default - you
> only need to use "raise X from Y" to set it to something *else*.
>
Absolutely - I can't think of a reason to want to reraise an existing
exce
> reset a variable explicitly to its default value.
In that case, would the best syntax be:
raise Exception() from Ellipsis
or:
raise Exception() from ...
? I kinda like the second - it feels more self-descriptive to me than "from
Ellipsis" - but there's the counter-argum
ions of
> "fill this in from somewhere else", and since we really just want a
> known sentinel object that isn't None and isn't a meaningful type like
> the boolean singletons...
>
It's cute yet seems appropriate ... I quite like it.
Tim Delaney
NoException__' confusing?
Seems perfectly expressive to me so long as it can't itself be raised.
Tim Delaney
___
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
ssive conflicts would fail.
4. (Optional) in 3.3, provide a way to get a dictionary with random salt
(i.e. not wait for attack).
Tim Delaney
___
Python-Dev mailing list
Python-Dev@python.org
http://mail.python.org/mailman/listinfo/python-dev
Unsubscribe:
On 17 January 2012 10:14, Tim Delaney wrote:
> On 17 January 2012 09:23, Paul McMillan wrote:
>
>> This is why the "simply throw an error" solution isn't a complete fix.
>> Making portions of an interface unusable for regular users is clearly
>> a bad th
he non-deterministic behaviour in pathological cases,
which we would presumably need new tests for.
Thoughts?
Tim Delaney
___
Python-Dev mailing list
Python-Dev@python.org
http://mail.python.org/mailman/listinfo/python-dev
Unsubscribe:
http://mail.pyth
On 3 January 2012 09:55, Raymond Hettinger wrote:
>
> On Jan 2, 2012, at 2:09 PM, Tim Delaney wrote:
>
> I'd also point out that if you're expecting braces, not having them can
> make the code less readable.
>
>
> If a programmer's mind explodes whe
se braces.
I'd also point out that if you're expecting braces, not having them can
make the code less readable. A consistent format tends to make for more
readable code.
Cheers,
Tim Delaney
___
Python-Dev mailing list
Python-Dev@python.org
http:
On 30 December 2011 06:59, Tim Delaney wrote:
> +0 to exposing the salt as a constant (3.3+ only) - or alternatively
> expose a hash function that just takes an existing hash and returns the
> salted hash. That would make it very easy for anything that wanted a salted
> hash to get o
>
> +1 to option c (environment variable) as an override. And/or maybe an
> override on the command line.
>
That obviously should have said option b (environment variable) ...
Tim Delaney
___
Python-Dev mailing list
Python-Dev@pyt
1 - 100 of 141 matches
Mail list logo
