) in order to simplify
exiting a generator expression early.
So I like the proposed change. I find it elegant and very Pythonic. +1
for me.
--
Steven D'Aprano
___
Python-Dev mailing list
Python-Dev@python.org
http://mail.python.org/mailman/listinfo
On Wed, 21 Jan 2009 03:10:24 pm Terry Reedy wrote:
Steven D'Aprano wrote:
...
In a generator expression, we have:
yielded-expr for-clause if-clause
while the corresponding nested statements are:
for-clause if-clause yielded-expr
The three clauses are neither in the same order
the extra functionality, but if
it does, people will ask why permutations doesn't as well.
--
Steven D'Aprano
___
Python-Dev mailing list
Python-Dev@python.org
http://mail.python.org/mailman/listinfo/python-dev
Unsubscribe:
http://mail.python.org
Michael Foord wrote:
Don't we have a pretty-print API - and isn't it spelled __str__ ?
Not really. If it were as simple as calling str(obj), there would be no
need for the pprint module. In any case, it seems that the pprint module
actually calls repr() on objects other than dicts, tuples
Eric Smith wrote:
Terry Reedy wrote:
Ron Adam wrote:
Steven D'Aprano wrote:
Michael Foord wrote:
Don't we have a pretty-print API - and isn't it spelled __str__ ?
Not really. If it were as simple as calling str(obj), there would be
no need for the pprint module.
I agree. And when I
Raymond Hettinger wrote:
The arguments for and against the patch could be brought against
partial()
itself, so I don't understand the -1's at all.
Quite so, but that doesn't justify adding more capabilities to partial().
I concur with Collin. Lever arguments are a road to bloat.
One
Guido van Rossum wrote:
On Thu, Feb 19, 2009 at 8:38 PM, Brett Cannon br...@python.org wrote:
On Thu, Feb 19, 2009 at 19:41, Benjamin Peterson benja...@python.org
wrote:
As we prepare to merge the io-c branch, the question has come up [1]
about the original Python implementation. Should it
Greg Ewing wrote:
Instead of defining things directly in foo.py, maybe it
should do
try:
from cFoo import *
except ImportError:
from pyFoo import *
Then the fast path will be taken if cFoo is available,
and you can directly import cFoo or pyFoo if you want.
For what it's worth,
On Wed, 4 Mar 2009 05:23:33 pm Glenn Linderman wrote:
The problem with the ordereddict/OrderedDict/odict is that there
are way too many possible orderings, and without being more
specific (InsertionSequenceOrderPreservingDictionary) people are
doing to think sort when they hear ordered.
For
Gisle Aas wrote:
Instead of introducing a sorteddict I would instead suggest that the
future should bring an odict with a sort method; possibly also
keys_sorted and items_sorted methods.
Instead of odict.sorted(), that can be spelled:
sorted(odict) # sort the keys
sorted(odict.values()) #
Glenn Linderman wrote:
FIFOdict ? Yeah, that blows the capitalization scheme, way, way out.
[...]
It is suggestive of queue behavior, and the items are a queue if looked
at from insertion, and traversal perspectives, if I understand
correctly.
Why is this relevant? Insertion and traversal
Leif Walsh wrote:
On Wed, Mar 4, 2009 at 7:53 AM, rdmur...@bitdance.com wrote:
I actually like StableDict best. When I hear that I think, ah, the
key order is stable in the face of insertions, unlike a regular dict.
Nor can I at the moment think of an alternative explanation of what a
.
--
Steven D'Aprano
___
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
the same, except it
can only recover from application crashes, not system crashes. I can't
tell you how many times such features have saved my hide!
--
Steven D'Aprano
___
Python-Dev mailing list
Python-Dev@python.org
http://mail.python.org/mailman
used is up to the application, but
naturally that might be specified by a user-configurable setting.
--
Steven D'Aprano
___
Python-Dev mailing list
Python-Dev@python.org
http://mail.python.org/mailman/listinfo/python-dev
Unsubscribe:
http
behaviour, and
Linux users may expect more fine control over application behaviour and
be willing to edit config files to get it.
--
Steven D'Aprano
___
Python-Dev mailing list
Python-Dev@python.org
http://mail.python.org/mailman/listinfo/python-dev
is that these are *application* decisions, not *language*
decisions. Python shouldn't be making those decisions, but should be
enabling application developers to make them.
--
Steven D'Aprano
___
Python-Dev mailing list
Python-Dev@python.org
http://mail.python.org
which cause data loss. This may be
more risky than the original strategy above (whatever that happens to
be.)
Complexity is not cost-free, and insisting that the more complex,
expensive solution is always best practice is wrong.
--
Steven D'Aprano
Tres, for some reason every time you reply to the list, you send TWO
copies instead of one:
To: python-dev@python.org
CC: Python Dev python-dev@python.org
Could you please fix that?
--
Steven D'Aprano
___
Python-Dev mailing list
Python-Dev
.
--
Steven D'Aprano
___
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
recent call last):
File stdin, line 2, in module
TypeError: list indices must be integers
Python does not promise that if x == y, you can use y anywhere you can
use x. Nor should it. Paul's declaration of abuse of __eq__ is
unfounded.
--
Steven D'Aprano
. The only
reason it's -0.5 rather than -1 is that (presumably) anyone who cares
about floating point correctness already knows to never trust the
compiler.
--
Steven D'Aprano
___
Python-Dev mailing list
Python-Dev@python.org
http://mail.python.org
is
sufficient to legally identify them. Those from Spanish and Portuguese
cultures usually have two family names as well as a personal name;
people from Indonesian, Burmese and Malaysian cultures often only use a
single name.
--
Steven D'Aprano
://tools.ietf.org/html/rfc5335
--
Steven D'Aprano
___
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
the result
to the last day of the next month.
Thoughts?
--
Steven D'Aprano
___
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
On Fri, 17 Apr 2009 12:29:11 pm Steven D'Aprano wrote:
Adding one month to 31st January could mean:
1: raise an exception
2: return 28th February (last day of February)
3: return 3rd April (1 month = 31 days)
4: return 2nd April (1 month = 30 days)
5: return 28th February (1 month = 4
the missus, who is a non-programmer, what date is one month
after 31st January and her answer was 2rd of March on leap years,
otherwise 3rd of March.
--
Steven D'Aprano
___
Python-Dev mailing list
Python-Dev@python.org
http://mail.python.org/mailman
1.0007
The solution isn't to add a goal to the plus operator, but to fix your
code to use a better algorithm:
y = 0.0
for i in xrange(1, 1001):
... y = i*step
...
y
1.0
Same with monthdelta.
--
Steven D'Aprano
___
Python-Dev mailing list
they do.
I suppose you could force people to write params.items() if params is a
dict, but it seems wrong to force an order on input data when it
doesn't require one.
--
Steven D'Aprano
___
Python-Dev mailing list
Python-Dev@python.org
http
probably be better off on comp.lang.python or
python-l...@python.org.
However, I believe that the normal way to prevent the generation
of .pyc files is to remove write access to the directory where
the .py files are.
--
Steven D'Aprano
___
Python
than 1e50.
...
I propose removing this feature for 3.1
No objections from me. +1
I propose changing the complex str and repr to behave like the
float version. That is, repr(4. + 10.j) should be (4.0 + 10.0j)
rather than (4+10j).
No objections here either. +0
--
Steven D'Aprano
:
filename = 'some path/some name'
I might call it a filename, I might think of it as a filename, but it
*isn't*, it's a string in a Python program. It isn't a filename until
it hits the file system, and in POSIX systems that makes it bytes.
--
Steven D'Aprano
when you try to work
with them. Please, let's see some code we can run, not more words.
--
Steven D'Aprano
___
Python-Dev mailing list
Python-Dev@python.org
http://mail.python.org/mailman/listinfo/python-dev
Unsubscribe:
http://mail.python.org
or license for more information.
f=open(chr(255),'w')
f.close()
import os
os.remove(chr(255))
Given that chr(255) is a valid filename on my file system, I would
consider it a bug if Python couldn't deal with a file with that name.
--
Steven D'Aprano
are still likely to confuse them.
Why not give it a more explicit name, such
as st_creationtime?
Speaking as somebody who thought the c in ctime meant creation, I'm +1
on this proposal with Greg's modification.
--
Steven D'Aprano
___
Python-Dev
On Tue, 16 Jun 2009 01:20:53 pm Cameron Simpson wrote:
I don't think all
pythons do immediate ref-counted GC.
Jython and IronPython don't. I don't know about PyPy, CLPython, Unladen
Swallow, etc.
--
Steven D'Aprano
___
Python-Dev mailing list
provides
pyc and pyo files?
--
Steven D'Aprano
___
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
.
Alpha, beta, kappa version?
--
Steven D'Aprano
___
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
installing, and then spending a few paranoid hours trying to determine
whether you've stumbled across a root kit or virus or whether they have
a legitimate reason to be there.
--
Steven D'Aprano
___
Python-Dev mailing list
Python-Dev@python.org
http
different files.
--
Steven D'Aprano
___
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
like a function to toggle between one and the other: that smacks
of relying on a global setting in a bad way. I suppose you could add an
optional argument to ProcessIOWrapper() to select between stdout,
stderr, or both together.
--
Steven D'Aprano
can
come up with additional use-cases.
--
Steven D'Aprano
___
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
/Function_composition
It doesn't appear to be standard in Ruby, but it seems to be commonly
requested, and a version is on Facets:
http://facets.rubyforge.org/apidoc/api/core/classes/Proc.html#M000161
--
Steven D'Aprano
___
Python-Dev mailing list
Python
:
compose(f, g, h)
lambda x: f(g(h(x)))
You need to read virtually the entire lambda before you can
distinguish it from some other arbitrary lambda:
lambda x: f(g(h))(x)
lambda x: f(g(x) or h(x))
lambda x: f(g(x)) + h(x)
etc.
--
Steven D'Aprano
as a mailing list:
http://www.python.org/mailman/listinfo/python-list
Good luck.
--
Steven D'Aprano
___
Python-Dev mailing list
Python-Dev@python.org
http://mail.python.org/mailman/listinfo/python-dev
Unsubscribe:
http://mail.python.org/mailman
.
--
Steven D'Aprano
___
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
Xavier Morel wrote:
Not being too eager to kill APIs is good, but giving rise to this kind of
living-dead APIs is no better in my opinion, even more so since Python has
lost one of the few tools it had to manage them (as DeprecationWarning was
silenced by default). Both choices are harmful to
Guido van Rossum wrote:
Point of order (repeated), please move this thread to python-ideas.
Isn't that cruel to the people reading python-ideas?
--
Steven
___
Python-Dev mailing list
Python-Dev@python.org
Terry Reedy wrote:
On 12/9/2011 5:17 AM, Nick Coghlan wrote:
As Chris pointed out though, the real problem with the repeatedly run
2to3 workflow is that it can make interpreting tracebacks from the
field *really* hard.
This just gave me the idea of tagging tracebacks with the Python version
Greg Ewing wrote:
Matt Joiner wrote:
ಠ_ಠ
What's up with these ?_? messages?
I think that, depending on the typeface you view it with, it is supposed to be
some sort of smiley: two big wide open square eyes with tightly pursed lips.
Presumably it is supposed to be a look of shock and
Steven D'Aprano wrote:
Greg Ewing wrote:
Matt Joiner wrote:
ಠ_ಠ
What's up with these ?_? messages?
I think that, depending on the typeface you view it with, it is supposed
to be some sort of smiley: two big wide open square eyes with tightly
pursed lips. Presumably it is supposed
Jim Jewett wrote:
My personal opinion is that accepting *and parsing* enough data for
this to be a problem
is enough of an edge case that I don't want normal dicts slowed down
at all for this; I would
therefore prefer that the change be restricted to such a compile-time
switch, with current
Christian Heimes wrote:
[...]
I propose an addition to the current Python C API:
int PyOS_URandom(char *buf, Py_ssize_t len)
Read len chars from the OS's RNG into the pre-allocated buffer buf.
The RNG should be suitable for cryptography.
Since some platforms may not have /dev/urandom, we
David Malcolm wrote:
When backporting the fix to ancient python versions, I'm inclined to
turn the change *off* by default, requiring the change to be enabled via
an environment variable: I want to avoid breaking existing code, even if
such code is technically relying on non-guaranteed
Benjamin Peterson wrote:
2012/1/5 Nick Coghlan ncogh...@gmail.com:
On Fri, Jan 6, 2012 at 10:07 AM, Steven D'Aprano st...@pearwood.info wrote:
Surely the way to verify the behaviour is to run this from the shell:
python -c print(hash(abcde))
twice, and see that the calls return different
Benjamin Peterson wrote:
2012/1/5 Steven D'Aprano st...@pearwood.info:
[...]
There's nothing obscure about directly testing the hash. That's about as far
from obscure as it is possible to get: you are directly testing the presence
of a feature by testing the feature.
It's obscure because
Glenn Linderman wrote:
On 1/5/2012 5:52 PM, Steven D'Aprano wrote:
At some point, presuming that there is no speed penalty, the behaviour
will surely become not just enabled by default but mandatory. Python
has never promised that hashes must be predictable or consistent, so
apart from
Victor Stinner wrote:
-if os.name in ('nt', 'os2'):
+if os.name in ('nt'):
This change is wrong: it should be os.name == 'nt'.
Or possibly os.name in ('nt', ) (note the comma).
--
Steven
___
Python-Dev mailing list
On 14/01/12 12:58, Gregory P. Smith wrote:
I do like *randomly seeding the hash*. *+1*. This is easy. It can easily be
back ported to any Python version.
It is perfectly okay to break existing users who had anything depending on
ordering of internal hash tables. Their code was already broken.
Victor Stinner wrote:
- Marc Andre Lemburg proposes to fix the vulnerability directly in
dict (for any key type). The patch raises an exception if a lookup
causes more than 1000 collisions.
Am I missing something? How does this fix the vulnerability? It seems to me
that the only thing this
Guido van Rossum wrote:
On Fri, Jan 13, 2012 at 5:58 PM, Gregory P. Smith g...@krypto.org wrote:
It is perfectly okay to break existing users who had anything depending on
ordering of internal hash tables. Their code was already broken. We
*will*provide a flag and/or environment variable that
python wrote:
jbk
[snip 560+ lines of quoted text]
Please delete irrelevant text when replying to digests, and replace the
subject line with a meaningful subject.
--
Steven
___
Python-Dev mailing list
Python-Dev@python.org
Antoine Pitrou wrote:
Le jeudi 19 janvier 2012 à 00:25 +0900, Stephen J. Turnbull a écrit :
You claim people won't use stable releases because of not enough
alphas? That sounds completely unrelated.
Surely testing is related to user perceptions of stability. More
testing helps reduce
Brett Cannon wrote:
And honestly, if we don't go with this I'm with Georg's comment in another
email of beginning to consider stripping the stdlib down to core libraries
to help stop with the bitrot (sorry, Paul). If we can't attract new
replacements for modules we can't ditch because of
Victor Stinner wrote:
The last solution is very simple: count collision and raise an
exception if it hits a limit. ...
According to my basic tests, a limit of 35 collisions
requires a dictionary with more than 10,000,000 integer keys to raise
an error. I am not talking about the attack, but
Benjamin Peterson wrote:
2012/1/20 Terry Reedy tjre...@udel.edu:
Since 'raise' means 're-raise the current error', 'raise as OtherError'
means (clearly to me, anyway) 're-raise the current error as OtherError'.
That doesn't make any sense. You're changing the exception completely
not
Guido van Rossum wrote:
On Fri, Jan 20, 2012 at 11:51 AM, Donald Stufft donald.stu...@gmail.comwrote:
On Friday, January 20, 2012 at 2:36 PM, Tres Seaver wrote:
On 01/20/2012 02:04 PM, Donald Stufft wrote:
Even if a MemoryException is raised I believe that is still a
fundamental change in
Terry Reedy wrote:
On 1/20/2012 11:17 AM, Victor Stinner wrote:
There is no perfect solutions, drawbacks of each solution should be
compared.
Amen.
One possible attack that has been described for a collision counting
dict depends on knowing precisely the trigger point. So let
Guido van Rossum wrote:
It should derive from BaseException.
RuntimeError meets that requirement, and it is an existing exception so there
are no issues with introducing a new built-in exception to a point release.
py issubclass(RuntimeError, BaseException)
True
--
Steven
Ethan Furman wrote:
The question I have at the moment is: should `raise as` be an error if
no exception is currently being handled?
I think so.
raise as Spam essentially means raise Spam with the context set to None.
That's actually only useful if the context otherwise wouldn't be None,
Paul McMillan wrote:
On Sat, Jan 21, 2012 at 4:19 PM, Jared Grubb jared.gr...@gmail.com wrote:
I agree; it sounds really odd to throw an exception since nothing is actually
wrong and there's nothing the caller would do about it to recover anyway.
Rather than throwing an exception, maybe you
Eli Bendersky wrote:
Hello,
Following an earlier discussion on python-ideas [1], we would like to
propose the following PEP for review. Discussion is welcome.
I think you need to emphasize that modules in __preview__ are NOT expected to
have a forward-compatible, stable, API. This is a
Eli Bendersky wrote:
try:
from __preview__ import thing
except ImportError:
import thing
So no need to target a very specific version of Python.
Yep, this is what I had in mind. And it appeared too trivial to place
it in the PEP.
Trivial and wrong.
Since thing and __preview__.thing
Terry Reedy wrote:
On 1/27/2012 2:54 PM, Guido van Rossum wrote:
On Fri, Jan 27, 2012 at 9:08 AM, Ethan Furmanet...@stoneleaf.us wrote:
Guido van Rossum wrote:
Did you consider to just change the
words so users can ignore it more easily?
Yes, that has also been discussed.
Speaking for
Benjamin Peterson wrote:
Hello everyone,
In effort to get a fix out before Perl 6 goes mainstream, Barry and I
have decided to pronounce on what we want for our stable releases.
What we have decided is that
1. Simple hash randomization is the way to go. We think this has the
best chance of
Michael Foord wrote:
On 27/01/2012 20:48, Steven D'Aprano wrote:
Eli Bendersky wrote:
try:
from __preview__ import thing
except ImportError:
import thing
So no need to target a very specific version of Python.
Yep, this is what I had in mind. And it appeared too trivial to place
Mark Shannon wrote:
Antoine Pitrou wrote:
On Sun, 29 Jan 2012 09:56:11 -0500
Benjamin Peterson benja...@python.org wrote:
2012/1/29 Mark Shannon m...@hotpy.org:
Hi,
Now that issue 13703 has been largely settled,
I want to propose my new dictionary implementation again.
It is a little more
Chris Withers wrote:
Every time I see things like the following I cry a little inside:
try:
try:
from py2stdliblocation import FooBar as Foo
except ImportError:
from py3stdliblocation import foo as Foo
except ImportError:
from pypilocation import Foo
The syntax is inelegant,
Terry Reedy wrote:
On 2/3/2012 6:18 PM, Steven D'Aprano wrote:
Now we're talking about having to add __preview__ into that mix too?
As I understand it, Guido nixed that idea. (Or did I imagine that?)
No, you are right, discussion should cease. It is already marked
'rejected' and listed
Paul Moore wrote:
On 4 February 2012 11:25, Steven D'Aprano st...@pearwood.info wrote:
It strikes me that it would be helpful sometimes to programmatically
recognise preview modules in the std lib. Could we have a recommendation
in PEP 8 that such modules should have a global variable called
Simon Cross wrote:
I think I'm -1 on a locale encoding because it refers to different
actual encodings depending on where and when it's run, which seems
surprising
Why is it surprising? Surely that's the whole point of a locale encoding: to
use the locale encoding, whatever that happens to be
Paul Moore wrote:
I would suggest that, assuming python-dev want to take ownership of
the module, one last-ditch attempt be made to contact Fredrik. We
should email him,
I wouldn't call email to be last-ditch. I call email first-ditch.
I would expect that a last-ditch attempt would include
Jim J. Jewett wrote:
Eli Bendersky wrote (in
http://mail.python.org/pipermail/python-dev/2012-February/116393.html ):
A package will be marked provisional by including the
following paragraph as a note at the top of its
documentation page:
I really would like some marker available from
Eric Snow wrote:
On Fri, Feb 10, 2012 at 8:10 PM, Eli Bendersky eli...@gmail.com wrote:
On Fri, Feb 10, 2012 at 22:13, Jim J. Jewett jimjjew...@gmail.com wrote:
Eli Bendersky wrote (in
http://mail.python.org/pipermail/python-dev/2012-February/116393.html ):
A package will be marked
Charles-François Natali wrote:
Hi,
Issue #8604 aims at adding an atomic file API to make it easier to
create/update files atomically, using rename() on POSIX systems and
MoveFileEx() on Windows (which are now available through
os.replace()). It would also use fsync() on POSIX to make sure data
Georg Brandl wrote:
Am 16.02.2012 11:14, schrieb Martin v. Löwis:
Am 16.02.2012 10:51, schrieb Victor Stinner:
2012/2/16 Martin v. Löwis mar...@v.loewis.de:
Maybe an alternative PEP could be written that supports the filesystem
copying use case only, using some specialized ns APIs? I really
Martin v. Löwis wrote:
* Ruby (1.9.3), the `Time class http://ruby-doc.org/core-1.9.3/Time.html`_
supports picosecond (10\ :sup:`-12`)
We must do better than Ruby: support arbritrary precision! :-D
Seriously, I do consider that a necessary requirement for the PEP (which
the Decimal type
Nick Coghlan wrote:
On Mon, Feb 20, 2012 at 11:55 PM, Antoine Pitrou solip...@pitrou.net wrote:
On Mon, 20 Feb 2012 23:23:13 +1000
Nick Coghlan ncogh...@gmail.com wrote:
Does anyone object to me naming myself PEP czar for PEP 3144?
“Tsar is a title used to designate certain European Slavic
Tshepang Lekhonkhobe wrote:
On Sat, Feb 25, 2012 at 05:10, Ned Batchelder n...@nedbatchelder.com wrote:
Has Python *ever* removed a feature except in X.0 releases?
I thought this happens all the time, but with deprecations first. Is
that not the case?
Hardly all the time. Only when
Vinay Sajip wrote:
Serhiy Storchaka storchaka at gmail.com writes:
n = str
Well, n to indicate that native string is required.
str indicates the native string type, because it *is* the native string type.
By definition, str = str in both Python 2.x and Python 3.x. There's no point
in
Armin Ronacher wrote:
Hi,
On 2/27/12 4:44 PM, mar...@v.loewis.de wrote:
Maybe I'm missing something, but there doesn't seem to be a benchmark
that measures the 2to3 performance, supporting the claim that it
runs two orders of magnitude slower (which I'd interpret as a
factor of 100).
My
Terry Reedy wrote:
On 2/27/2012 6:50 AM, Antoine Pitrou wrote:
'rc' makes sense to most people while 'c' is generally unheard of.
'rc' following 'a' and 'b' only makes sense to people who are used to it
and know what it means. 'c' for 'candidate' makes more sense to me both
a decade ago
M.-A. Lemburg wrote:
Victor Stinner wrote:
See also the PEP 351.
I read the PEP and the email explaining why it was rejected.
Just to be clear: the PEP 351 tries to freeze an object, try to
convert a mutable or immutable object to an immutable object. Whereas
my frozendict proposition doesn't
Vinay Sajip wrote:
Serhiy Storchaka storchaka at gmail.com writes:
Another pertinent question: What are disadvantages of PEP 414 is adopted?
It's moot, but as I see it: the purpose of PEP 414 is to facilitate a single
codebase across 2.x and 3.x. However, it only does this if your 3.x
Raymond Hettinger wrote:
On Feb 29, 2012, at 3:52 PM, Victor Stinner wrote:
I don't know if hardening Python is a compelling argument to add a new
builtin type.
It isn't.
Builtins are for general purpose use.
It is not something most people should use;
however, if it is a builtin, people
Raymond Hettinger wrote:
On Feb 27, 2012, at 10:53 AM, Victor Stinner wrote:
A frozendict type is a common request from users and there are various
implementations.
ISTM, this request is never from someone who has a use case.
Instead, it almost always comes from completers, people
who see
Armin Rigo wrote:
Hi Mark,
On Sun, Mar 4, 2012 at 18:34, Mark Shannon m...@hotpy.org wrote:
You can't solve the too much time, without solving the halting problem,
Not sure what you mean by that. It seems to me that it's particularly
easy to do in a roughly portable way, with alarm() for
On Thu, Mar 08, 2012 at 12:20:21PM +1000, Nick Coghlan wrote:
On Thu, Mar 8, 2012 at 11:42 AM, Benjamin Peterson benja...@python.org
wrote:
2012/3/7 Victor Stinner victor.stin...@gmail.com:
Can't we simply raise an error if the dict contains
non-string keys?
Sounds okay to me.
For
On Fri, Mar 09, 2012 at 05:38:05PM -0500, Yury Selivanov wrote:
Actually, I too noticed that you've dropped few crasher tests. I think
we need to keep them, to make sure that future development will not
introduce the same vulnerabilities. That's a common practice with
unit-testing.
The
Brian Curtin wrote:
On Tue, Mar 13, 2012 at 14:13, Kenneth Reitz m...@kennethreitz.com wrote:
I think the cheesehop trove classifiers would be the ideal way to
agnostically link to a page of packages related to the standard package in
question. No need for sort order.
Randomize the order for
1 - 100 of 1505 matches
Mail list logo
