On Jun 8, 2014, at 6:42 PM, Nick Coghlan wrote:
> >> I seem to remember a previous discussion that concluded that duck typing
> >> based on _fields was the way to go. (It's a public API, despite the _,
> >> due to name-tuple's attribute namespacing issues.)
> >
> >
> > Yes. That is the recomme
On Jun 7, 2014, at 6:25 AM, R. David Murray wrote:
>> I guess I could duck-type it based on the _fields attribute but that
>> feels implicit and fragile.
>>
>> What do you guys suggest?
>
> I seem to remember a previous discussion that concluded that duck typing
> based on _fields was the way
On Jun 1, 2014, at 9:17 AM, Antoine Pitrou wrote:
> Le 01/06/2014 10:11, Steven D'Aprano a écrit :
>>
>> My feeling is that the CPython standard library should be written for
>> CPython, that is, it should stick to the current naive implementation of
>> median, and if PyPy wants to speed the fu
On May 30, 2014, at 8:32 PM, Terry Reedy wrote:
> B. Lets assuming that turtle.py is, at least to some degree, fair game for
> fixes and enhancements. PSF Python PyLadies (Jessica Keller, Lynn Root) are
> participating in the 2014 GNOME Outreach Program for Women (OPW)
> https://wiki.python.o
On May 27, 2014, at 1:58 AM, Serhiy Storchaka wrote:
> Perhaps it is worth to add simple comment explaining why this is not
> equivalent to just list(zip(it, range(n))). Otherwise it can be
> unintentionally "optimized" in future.
FWIW, that is covered by the test cases.
If you substitute lis
and 90755 by Raymond Hettinger 8 hours
> ago. From earliest to lastest:
>
> c67a19e11a71
> 7c5f1b200a24
> 35ea333f43bd
> 31211947387b
> 854fd62f
>
> If there was any notice on the Committer's list about not making commits, I
> did not get it. In fact, I do
On May 11, 2014, at 6:57 AM, Steve Dower wrote:
> Thanks.
>
> For those who missed the earlier discussions, Martin v. Löwis has handed over
> responsibility for the Windows installers. It sounds like Brett Cannon and I
> are both in a position to build 2.7 right now, and I hope to simplify th
If there is anyone here with an interest in web-spiders,
it would be nice if someone else could take a look at
http://bugs.python.org/issue21469
which addresses the risk of false positives with the robots.txt parser.
Raymond
___
Python-Dev maili
On May 10, 2014, at 4:15 PM, Stefan Behnel wrote:
> Total +1 on keeping these little bits around.
Since all of you want a warning, I'll add one back
but with improved wording.
I'm not all at comfortable with the wording of the second sentence.
I was the author of the SystemRandom() class and I
On May 10, 2014, at 2:54 PM, Antoine Pitrou wrote:
> It's not about being bright or not, it's about being
> *willing* to eat walls of text. However pleasant it may be for some
> people to *write* documentation, for most readers (and especially
> non-native English readers, who read more slowly a
On May 10, 2014, at 2:18 PM, Alex Gaynor wrote:
> I think this change is a considerable usability regression for the
> documentation. Right now the warnings about CSPRNGs are hidden in the
> introductory paragraph, which users are likely to skip
In the past couple of years, we've grown an un
On Apr 18, 2014, at 1:21 AM, Jeff Allen wrote:
> The "think of tuples like a struct in C" explanation immediately reminded me
> that ...
>
> On 16/04/2014 21:42, Taavi Burns wrote (in his excellent notes from the
> language summit):
>> The demographics have changed. How do
>> we change the d
On Apr 18, 2014, at 7:31 PM, Nick Coghlan wrote:
> After spending some time talking to the folks at the PyCon Twisted
> sprints, they persuaded me that adding back the iterkeys/values/items
> methods for mapping objects would be a nice way to eliminate a key
> porting hassle for them (and likely
On Feb 18, 2014, at 1:09 PM, Terry Reedy wrote:
> While the function could be implemented as one 70-line function, it happens
> to be implemented as a 4-line wrapper for a completely undocumented
> (Untokenizer class with 4 methods. (It is unmentioned in the doc and there
> are currently no d
On Mar 26, 2014, at 1:31 PM, Marko Rauhamaa wrote:
> I have made a full implementation of a balanced tree and would like to
> know what the process is to have it considered for inclusion in Python
> 3.
>
> To summarize, the implementation closely parallels dict() features and
> resides in _coll
On Jan 25, 2014, at 4:01 PM, Brett Cannon wrote:
> As the author of the PEP and I can say that `lambda (x, y): x + y` can just
> as easily be expressed as `lambda x, y: x + y` and then be called by using
> *args in the argument list. Anything that gets much fancier typically calls
> for a def
On Jan 25, 2014, at 5:29 AM, Ezio Melotti wrote:
> Nick also suggested to document
> our deprecation policy in PEP 5 (Guidelines for Language Evolution:
> http://www.python.org/dev/peps/pep-0005/ ).
Here's a few thoughts on deprecations:
* If we care at all about people moving to Python 3, the
On Jan 14, 2014, at 9:12 PM, Antoine Pitrou wrote:
> I'm +1 on the sidefile approach. +0 on the various buffer approaches.
> -0.5 on the current "sprinkled everywhere" approach.
I concur with Antoine except that I'm a full -1 on commingling
generated code with hand edited code. Sprinked every
On Oct 28, 2013, at 1:16 PM, Victor Stinner wrote:
> so what is the
> status of the PEP 455 (TransformDict)?
I'm giving a thorough evaluation of the proposal
and am devoting chunks of time each weekend
to reviewing the email threads, the links provided
in the PEPs, looking at how well the TD f
On Oct 20, 2013, at 9:21 AM, Eric Snow wrote:
> If anyone is interested in having a (faithful) C implementation of
> OrderedDict for the 3.4 release, I have a patch up [1]. My interest
> in having the patch applied is relative to proposals that won't apply
> to 3.4, so I haven't felt the need t
Two of the new context managers in contextlib are now wrapped in pass-through
factory functions. The intent is to make the help() look cleaner. This
practice does have downsides however.
The usual way to detect whether something is usable with a with-statement is to
check the presence of th
On Oct 15, 2013, at 4:24 PM, Nick Coghlan wrote:
> this thread still epitomises everything that sucks about soul destroying,
> energy draining bikeshed painting that makes me wonder why I ever bother
> trying to make anything better.
>
FWIW, here's a little history:
* Last year, one of my
On Oct 15, 2013, at 5:55 AM, Larry Hastings wrote:
> I'd like to propose much the same thing for Argument Clinic: check it in now,
> before 3.4a4, and let it bake in trunk a little before feature freeze at beta
> 1 while I run around and finish the documentation.
This is a good plan.
"Lettin
On Oct 12, 2013, at 4:30 PM, Ethan Furman wrote:
>>
>> When you ask someone to describe what
>> "try: f() except SomeException: pass" does,
>> they will say that it ignores the exception.
>
> And they would be right in that case.
>
>
>> FWIW, I presented this to 2500+ people in the keynote
>
On Oct 12, 2013, at 1:41 PM, Ethan Furman wrote:
> . break_on reads just fine to me, although leave_on is probably better.
Sorry, these are both really bad.
I've user tested ignore() and had good results.
It makes the intention of the code very clear.
When you ask someone to describe what
"t
On Oct 5, 2013, at 12:42 PM, Serhiy Storchaka wrote:
> Please remember me, what was common decision about CPython-only optimizations
> which change computation complexity?
IIRC, it is okay optimize C code for just about anything, but we don't
want to alter the pure python code after from idiom
On Oct 4, 2013, at 2:14 PM, Antoine Pitrou wrote:
> I think "usability tests" should be conducted on people who actually
> have a need for the API. Otherwise they simply don't make sense: if you
> don't need an API, then you don't have to learn / understand it either.
You're right. Students do
On Oct 4, 2013, at 2:06 PM, Victor Stinner wrote:
> I'm not convinced by your usability test.
You're not the one who needs to be convinced ;-)
Please do conduct your own API tests and report back.
This is necessary for a new class like TransformDict
that was constructed from scratch and pro
On Sep 22, 2013, at 6:16 PM, Ethan Furman wrote:
> Are we close to asking for pronouncement?
When you're ready, let me know.
In the meantime, I conducting usability tests on students in Python classes
and researching how well it substitutes for existing solutions for
case insensitive diction
On Sep 23, 2013, at 7:15 AM, Nick Coghlan wrote:
> With the last round of updates, I believe PEP 453 is ready for
> Martin's pronouncement.
Personally, I'm very excited and happy that this or something like it
is coming close to fruition.
My experiences in userland suggest that this will be
On Sep 14, 2013, at 1:32 PM, Ned Deily wrote:
> The
> most recent Developer Tools for 10.8 and 10.7 systems, Xcode 4.6.x, have
> a mature clang but do not provide a 10.6 SDK. Even with using an SDK,
> it's still possible to end up inadvertently linking with the wrong
> versions of system li
I was exercising the alpha two release of 3.4 and noticed that
it is still being built under GCC 4.2.1.
Is there any reason we have to use an old compiler?
I would like to see it built under the latest version of Clang
(like the other tools on the Mac) or under GCC 4.8.1.
I've better using the
On Sep 10, 2013, at 4:28 AM, Antoine Pitrou wrote:
> In http://bugs.python.org/issue18986 I proposed adding a new mapping
> type to the collections module.
I would *really* like for this to start outside the standard library.
It needs to mature with user feedback before being dumped
in the coll
> The most reasonable thing to do would probably be to share the same
> dummy object between setobject.c and dictobject.c, then.
> Raymond, it would be nice if you could take a look!
Thanks, I will look at it shortly.
Raymond
On Sun, Aug 18, 2013 at 11:46 AM, Antoine Pitrou wrote:
> On Sun,
On Aug 2, 2013, at 8:47 PM, Eli Bendersky wrote:
> I was looking around the Objects directory and noticed that we have
> enumobject.h/c with the enumobject structure for "enumerate" and "reversed".
> This is somewhat confusing now with Lib/enum.py and will be doubly confusing
> if we ever dec
On Jul 21, 2013, at 5:32 PM, Ned Deily wrote:
> In article <252c50d8-c23d-438d-bae1-b22e0d65a...@gmail.com>,
> Raymond Hettinger wrote:
>> Our current Mac OS X builds use GCC-4.2.
>>
>> On Python2.7, I ran a comparison of gcc-4.2.1 builds
>> versus gcc-4.8
Our current Mac OS X builds use GCC-4.2.
On Python2.7, I ran a comparison of gcc-4.2.1 builds
versus gcc-4.8.1 and found that the latter makes a much
faster Python. PyBench2.0 shows the total running time
dropping from 5653ms to 4571ms. The code is uniformly
better in just about every category.
On Jul 14, 2013, at 6:32 AM, David Beazley wrote:
> I honestly don't have any particular thoughts about PLY vs. other parser
> generators and the merits of their inclusion (or not) in the standard
> library.
I would love to have PLY in the standard library.
It would open up a whole new world
On Jul 4, 2013, at 2:34 AM, Brett Cannon wrote:
> The loss of the ability to figure out the class from an unbound method seems
> quite an annoying step back from an introspection point of view.
>
> It's only annoying if you take the perspective that methods are somehow
> special compared to f
On Jun 24, 2013, at 10:12 PM, Benjamin Peterson wrote:
> Raymond, go ahead and reapply your change.
If you don't mind, I think you should be the one to undo your own reversions.
Thank you,
Raymond
___
Python-Dev mailing list
Python-Dev@python.org
On Jun 24, 2013, at 4:07 AM, Victor Stinner wrote:
> Out of curiosity, do you know (remember) how was the number 62 chosen?
> Is it a compromise between memory usage and performances? 62 is
> surprising because it is not a power of two :-)
>
> Is it to just have 64 (2+62) pointers in the struct
On Jun 23, 2013, at 6:52 PM, Scott Dial wrote:
> Nowadays, cache lines are still 64 bytes but pointers are 8 bytes, and
> we still allocating on 16 byte alignment, so you have a 25% chance of a
> cache miss now.
Honestly, I'm not sure what you're arguing for or against.
The struct should to be
On Jun 18, 2013, at 12:00 AM, Gregory P. Smith wrote:
> Why did you do this in the 2.7 branch?
>
> It hasn't been done in 3.3 or default
I worked on the 2.7 branch first because that was the one I had loaded
and the one where I did timings and code disassembly. I intended to
post it to 3.3 an
Does anyone know what we would need to do to get Python in the Apple
application store as a free App?
The default security settings on OS X 10.8 block the installation of the DMG
(or any software downloaded outside the app store). A number of my students
are having difficulty getting around i
On May 14, 2013, at 9:39 AM, Gregory P. Smith wrote:
> Bad: doctests.
I'm hoping that core developers don't get caught-up in the "doctests are bad
meme".
Instead, we should be clear about their primary purpose which is to test
the examples given in docstrings. In many cases, there is a gre
On May 15, 2013, at 4:32 AM, Christian Tismer wrote:
> What is the current status of this discussion?
> I'd like to know whether it is a considered alternative implementation.
As far as I can tell, I'm the only one working on it (and a bit slowly at that).
My plan is to implement it for frozens
On May 12, 2013, at 8:26 PM, Eli Bendersky wrote:
> Thanks for the insights, Raymond. I don't think anyone is planning on rushing
> anything. We still have to get the enum module itself committed and a serious
> review process has just started for that, so it will take time.
>
> There's no ge
After the long design effort for the enum module,
I'm sure there will be a forthcoming effort to apply
them pervasively throughout the standard library.
I would like to ask for a little restraint and for there to
be individual cost/benefit evaluations for each case.
On the plus-side, the new int
On Apr 6, 2013, at 2:02 PM, Benjamin Peterson wrote:
> we need to talk about how many more 2.7 releases there are
> going to be. At the release of 2.7.0, I thought we promised 5 years of
> bugfix maintenance, but my memory may be fuddled.
I don't we need to make any "promises" beyond 5 years,
On Mar 25, 2013, at 2:16 PM, Victor Stinner wrote:
> Hi,
>
> I just realized that the Python peephole optimizer removes useless
> instructions like numbers and strings between other instructions,
> without raising an error nor emiting an error. Example:
>
> $ python -Wd -c 'print "Hello"; "Wor
On Mar 20, 2013, at 12:38 PM, Barry Warsaw wrote:
> Right. Ultimately, I think IDLE should be a separate project entirely, but I
> guess there's push back against that too.
The most important feature of IDLE is that it ships with the standard library.
Everyone who clicks on the Windows MSI on
On Jan 6, 2013, at 1:40 PM, Kristján Valur Jónsson
wrote:
> The memory part is also why I am interested in this approach.
> Another thing has been bothering me. This is the fact that with the default
> implementation, the smll table is only ever populated up to a certain
> percentage, I cant
On Jan 3, 2013, at 2:22 AM, Maciej Fijalkowski wrote:
> Hello everyone.
>
> Thanks raymond for writing down a pure python version ;-)
Thanks for running with it.
>
> I did an initial port to RPython for experiments. The results (on
> large dicts only) are inconclusive - it's either a bit fas
On Dec 11, 2012, at 1:13 AM, Antoine Pitrou wrote:
>>
>> On Dec 10, 2012, at 2:48 AM, Christian Heimes
>> wrote:
>>
>>> On the other hand every lookup and collision checks needs an
>>> additional multiplication, addition and pointer dereferencing:
>>>
>>> entry = entries_baseaddr + sizeof(Py
On Dec 13, 2012, at 7:00 PM, Chris Jerdonek wrote:
> On Thu, Dec 13, 2012 at 6:48 PM, R. David Murray
> wrote:
>> On Thu, 13 Dec 2012 20:21:24 -0500, Trent Nelson wrote:
>>>- Use a completely separate clone to house all the intermediate
>>> commits, then generate a diff once
On Dec 10, 2012, at 4:02 AM, Serhiy Storchaka wrote:
> On 10.12.12 05:30, Raymond Hettinger wrote:
>> On Dec 9, 2012, at 10:03 PM, MRAB > <mailto:pyt...@mrabarnett.plus.com>> wrote:
>>> What happens when a key is deleted? Will that leave an empty slot in
>>
On Dec 10, 2012, at 7:04 PM, Mark Shannon wrote:
>> Another approach is to pre-allocate the two-thirds maximum
>> (This is simple and fast but gives the smallest space savings.)
>
> What do you mean by maximum?
A dict with an index table size of 8 gets resized when it is two-thirds full,
so th
On Dec 10, 2012, at 1:38 PM, PJ Eby wrote:
> Without numbers it's hard to say for certain, but the advantage to
> keeping ordered dictionaries a distinct type is that the standard
> dictionary type can then get that extra bit of speed in exchange for
> dropping the ordering requirement.
I expec
On Dec 10, 2012, at 4:06 AM, Mark Shannon wrote:
>> Instead, the 24-byte entries should be stored in a
>> dense table referenced by a sparse table of indices.
>
> What minimum size and resizing factor do you propose for the entries array?
There are many ways to do this. I don't know which is
On Dec 10, 2012, at 2:48 AM, Christian Heimes wrote:
> On the other hand every lookup and collision checks needs an additional
> multiplication, addition and pointer dereferencing:
>
> entry = entries_baseaddr + sizeof(PyDictKeyEntry) * idx
Currently, the dict implementation allows alternati
On Dec 9, 2012, at 10:03 PM, MRAB wrote:
> What happens when a key is deleted? Will that leave an empty slot in
> the entry array?
Yes. See the __delitem__() method in the pure python implemention
at http://code.activestate.com/recipes/578375
> If so, will the array be compacted if the propor
The current memory layout for dictionaries is
unnecessarily inefficient. It has a sparse table of
24-byte entries containing the hash value, key pointer,
and value pointer.
Instead, the 24-byte entries should be stored in a
dense table referenced by a sparse table of indices.
For example, the di
On Sep 11, 2012, at 6:32 AM, Christian Heimes wrote:
>
> maybe you have noticed a bunch of commits I made the last couple of
> days.
I noticed! Thank you for all the work to improve quality.
Raymond___
Python-Dev mailing list
Python-Dev@python.org
On Mountain Lion, the default security settings only allow installation of
applications downloaded from the Mac App Stored and "identified developers".
We need to either become an "identified developer" or include some instructions
on how to change the security settings (System Preference -- Gen
Hello all,
I'll soon be starting the edits of Whatsnew for 3.3.
When I did this for 3.2, it took over 150 hours of work to research all the
changes. This time there are many more changes, so my previous process won't
work (reviewing every "new in 3.3" entry in the docs, every entry in the
vol
On Aug 1, 2012, at 1:46 AM, Mark Shannon wrote:
>
> '''
> Being able to pre-allocate lists based on the expected size, as estimated by
> __length_hint__,
> can be a significant optimization.
> PyPy has been observed to run some code slower than CPython, purely because
> this optimization is ab
On Jul 18, 2012, at 3:30 AM, Nick Coghlan wrote:
> - Eugene Toder's patch to add an AST optimisation step to the compiler
> chain (http://bugs.python.org/issue11549) (I've asked Eugene about
> this patch more recently and his current thought is that subsequent
> improvements to the peephole optim
On Jul 16, 2012, at 12:36 AM, Stefan Behnel wrote:
> I'd like to more visibly repeat my suggestion to make this a slot method
> "tp_length_hint()" in extension types that returns a Py_ssize_t.
That is merely an implementation detail, but it would be a nice improvement.
Raymond
___
On Jul 15, 2012, at 7:22 AM, Antoine Pitrou wrote:
> On Mon, 16 Jul 2012 00:08:41 +1000
> Nick Coghlan wrote:
>> Right, I agree on the value in being able to return something to say "this
>> cannot be converted to a concrete container".
>
> Who would be able to return that, apart from trivial c
On Jul 16, 2012, at 1:37 AM, Mark Shannon wrote:
> To quote from PEP 424:
>
>> Rationale
>> =
>> Being able to pre-allocate lists based on the expected size, as estimated by
>> ``__length_hint__``, can be a significant optimization. CPython has been
>> observed to run some code faster t
On Jul 1, 2012, at 5:01 AM, Stefan Behnel wrote:
> To address the main problem of users not finding what they need, what about
> simply extending the docstring of the grouper()
Here's a small change to the docstring:
http://hg.python.org/cpython/rev/d32f21d87363
FWIW, if you're interested i
On Jun 30, 2012, at 10:44 PM, Stefan Behnel wrote:
>>
>> Another addition could be a new subsection on grouping (chunking) that
>> would discuss post-processing of grouper (as discussed above), as well as
>> other recipes, including ones specific to strings and sequences. It would
>> essentially
On Jun 18, 2012, at 12:35 PM, Antoine Pitrou wrote:
> You are right. I was thinking 50 nanoseconds (which for a - relatively
> high-end - 3GHz CPU puts us at 150 cycles).
The last guidance I read from Intel said that
a cache miss was roughly as expensive as a floating-point divide.
When a dicti
On Jun 14, 2012, at 4:32 AM, Kristján Valur Jónsson wrote:
> I would like to two or more compile time
> settings to choose from: Memory optimal, speed optimal, (and mix).
A compile time option would be nice.
The default should be what we've had though.
The new settings cause a lot more collis
On Jun 13, 2012, at 2:37 PM, Mark Shannon wrote:
> I think that for combined tables a growth factor of x2 is best,
> but I don't have any hard evidence to back that up.
I believe that change should be reverted.
You've undone work that was based on extensive testing and timings of many
python
On Jun 13, 2012, at 10:35 AM, Eli Bendersky wrote:
> Did you mean to send this to the list, Raymond?
Yes. I wanted to find-out whether someone approved changing
all the dict tunable parameters. I thought those weren't supposed
to have changed. PEP 412 notes that the existing parameters
were
On May 18, 2012, at 11:24 AM, Barry Warsaw wrote:
> At what point should we cut over docs.python.org to point to the Python 3
> documentation by default? Wouldn't this be an easy bit to flip in order to
> promote Python 3 more better?
My experience teaching and consulting suggests that this wou
On Apr 18, 2012, at 1:38 PM, Guido van Rossum wrote:
>
> Let's change this to something more reasonable, e.g.
>
> """
> If operators with different priorities are used, consider adding
> whitespace around the operators with the lowest priority(ies). This is
> very much to taste, however, never
We should publish some advice on creating content managers.
Context managers are a general purpose tool but have a primary
use case of creating and releasing resources. This creates an
expectation that that is what the context managers are doing unless
they explicitly say otherwise.
For example
On Apr 11, 2012, at 2:49 AM, Jim Jewett wrote:
> I believe PEP 418 (or at least the discussion) would benefit greatly
> from a glossary to encourage people to use the same definitions.
This sort of information is a good candidate for the HOW-TO section
of the docs.
Raymond
Just to clarify my previous post.
It seems clear that benchmarking and timeout logic would benefit from a clock
that cannot be adjusted by NTP.
I'm unclear on whether time.sleep() will be based on the same clock so that
timeouts and sleeps are on the same basis.
For scheduling logic (such as t
On Apr 7, 2012, at 3:08 AM, Paul Moore wrote:
> Use cases:
>
> Display the current time to a human (e.g. display a calendar or draw a
> wall clock): use system clock, i.e. time.time() or
> datetime.datetime.now().
> Event scheduler, timeout: time.monotonic().
> Benchmark, profiling: time.clock()
On Mar 20, 2012, at 5:37 PM, Antoine Pitrou wrote:
> Georg Brandl wrote:
>> Hi all,
>>
>> recently I've grown a bit tired of seeing our default Sphinx theme,
>> especially as so many other projects use it. I decided to play around
>> with something "clean" this time, and this is the result:
>>
On Mar 16, 2012, at 4:54 AM, Nick Coghlan wrote:
> Don't forgot you also have the option of splitting out a separate
> HOWTO tutorial section, leaving the main docs as a pure API reference.
> (I personally find that style easier to use than the ones which try to
> address both needs in the main m
On Feb 29, 2012, at 4:23 PM, Victor Stinner wrote:
> One of my colleagues implemented recently its own frozendict class
> (which the "frozendict" name ;-)
I write new collection classes all the time.
That doesn't mean they warrant inclusion in the library or builtins.
There is a use case for Lis
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 will be drawn
to frozend
On Feb 29, 2012, at 1:08 PM, Paul Moore wrote:
> As it stands, I don't find the PEP compelling. The hardening use case
> might be significant but Victor needs to spell it out if it's to make
> a difference.
If his sandboxing project needs it, the type need not be public.
It can join dictproxy an
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 that we have a frozenset
On Jan 29, 2012, at 6:11 PM, John O'Connor wrote:
> On Sat, Jan 28, 2012 at 3:07 PM, Benjamin Peterson
> wrote:
>> But why would you want to pass a float? It seems like API abuse to me.
>>
>
> Agreed. Anything else seems meaningless.
I concur. This is very much a non-problem.
There is no ne
On Jan 26, 2012, at 7:19 PM, Ethan Furman wrote:
> One of the open issues from PEP 3134 is suppressing context: currently there
> is no way to do it. This PEP proposes one.
Thanks for proposing fixes to this issue.
It is an annoying problem.
Raymond
__
On Jan 2, 2012, at 4:27 PM, Nick Coghlan wrote:
> With my perception of the status quo corrected, I can stop worrying
> about preserving a non-existent consistency.
+1 QOTD
Raymond
___
Python-Dev mailing list
Python-Dev@python.org
http://mail.python
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 when they look at the simple and beautiful
examples in K&R's The C Programming Language, then they've got pro
On Jan 2, 2012, at 12:31 PM, Benjamin Peterson wrote:
> I might add that assuming you have braces, PEP 7 would want you to format it
> as
>
> if (cond) {
>statement;
> }
> else {
>more_stuff;
> }
>
Running ``grep -B1 else Objects/*c`` shows that we've happily lived with a
mixture o
On Jan 1, 2012, at 8:44 PM, Nick Coghlan wrote:
> I've been having an occasional argument with Benjamin regarding braces
> in 4-line if statements:
>
> if (cond)
>statement;
> else
>statement;
>
> vs.
>
> if (cond) {
>statement;
> } else {
>statement;
> }
Really? Do we
FWIW, Uncle Timmy considers the non-randomized hashes to be a virtue.
It is believed that they give us better-than-random results for commonly
encountered datasets. A change to randomized hashes would have a
negative performance impact on those cases.
Also, randomizing the hash wreaks havoc on do
On Dec 12, 2011, at 7:56 PM, Ben Wolfson wrote:
> I personally would prefer (1) to (2) or (3), and (3) to (2), had I my
> druthers, but it doesn't matter a *whole* lot to me; I'd prefer any of
> them to nothing (or to changing the docs to reflect the current batty
> behavior).
+1 on changing the
On Dec 6, 2011, at 7:23 PM, Cameron Simpson wrote:
> This assures that files are flushed [...]
>
> It does not. It _ensures_ that files are flushed. The doco style "affirmative
> tone" _assures_. The coding practice _ensures_!
>
> Pedanticly,
> --
> Cameron Simpson
I can assure you that I'v
When updating the documentation, please don't go overboard with warnings.
The docs need to be worded affirmatively -- say what a tool does and show how
to use it correctly.
See http://docs.python.org/documenting/style.html#affirmative-tone
The docs for the subprocess module currently have SEVEN w
On Oct 24, 2011, at 5:58 AM, Ezio Melotti wrote:
> Hi,
> our current deprecation policy is not so well defined (see e.g. [0]), and it
> seems to me that it's something like:
> 1) deprecate something and add a DeprecationWarning;
> 2) forget about it after a while;
> 3) wait a few versions unt
On Nov 25, 2011, at 6:18 PM, Jesus Cea wrote:
> On 12/11/11 16:56, Éric Araujo wrote:
>> Ezio and I chatted a bit about his on IRC and he may try to write
>> a Python parser for Misc/NEWS in order to write a fully automated
>> merge tool.
>
> Anything new in this front? :-)
To me, it would make
201 - 300 of 1487 matches
Mail list logo
