>> * New method (proposed by Shane Holloway): s1.isdisjoint(s2).
>> Logically equivalent to "not s1.intersection(s2)" but has an
>> early-out if a common member is found.
[MvL]
> I'd rather see iterator versions of the set operations.
Interesting idea. I'm not sure I see how to make it work.
On Dec 3, 2010, at 10:05 AM, Guido van Rossum wrote:
> Regardless of what I or others may have said before, I am not
> currently a fan of adding transform() to either str or bytes.
Just to clarify, is your preference to go back to the Python 2.x way
and use encode()/decode() for both unicode en
On Dec 5, 2010, at 3:36 AM, Vinay Sajip wrote:
> I've just been notified via being added to the nosy list of
>
> http://bugs.python.org/issue10627
>
> about the deprecation of ConfigParser for 3.2. I presume I was added to this
> list because logging.config uses ConfigParser, but logging.config
On Dec 6, 2010, at 11:40 AM, Fred Drake wrote:
> On Mon, Dec 6, 2010 at 2:21 PM, Raymond Hettinger
> wrote:
>> We really ought to stop with the SafeFoo naming convention.
>> It is only descriptive to the person who wrote the class or function,
>> not to the user who
On Dec 9, 2010, at 9:02 AM, Brian Quinlan wrote:
>
> On Dec 9, 2010, at 4:26 AM, Thomas Nagy wrote:
>
>> Hello,
>>
>> I am looking forward to replacing a piece of code
>> (http://code.google.com/p/waf/source/browse/trunk/waflib/Runner.py#86) by
>> the futures module which was announced in py
On Dec 9, 2010, at 2:18 PM, Nick Coghlan wrote:
> On Fri, Dec 10, 2010 at 2:41 AM, raymond.hettinger
> wrote:
>> @@ -588,7 +593,12 @@
>> pointing to the original callable function. This allows wrapped functions
>> to
>> be introspected. It also copies :attr:`__annotations__` if defined.
On Dec 9, 2010, at 12:29 PM, Alexander Belopolsky wrote:
>
> The str type already has 40+ methods many of which are not well-suited
> to handle the complexities inherent in Unicode. Rather than rushing
> in two more methods that will prove to be about as useful as
> str.swapcase(), lets conside
Does anyone know why this needed a separate module and so many accessor
functions?
ISTM it mostly could have been reduced to single call returning a nested
dictionary.
Raymond
from sysconfig import *
import json
def sysconf():
return dict(paths = get_paths(),
config_vars
On Dec 10, 2010, at 6:20 AM, Éric Araujo wrote:
> Final note: with 3.2 being in beta, I don’t know how much can be changed
> now.
Part of the purpose of a beta, and in our case, two betas is to give
people a chance to exercise new APIs and fix them before they
become set in stone two months later
On Dec 10, 2010, at 12:56 PM, Antoine Pitrou wrote:
> On Fri, 10 Dec 2010 12:27:26 -0800
> Raymond Hettinger wrote:
>>
>> IMO, sysconfig did not warrant a whole module.
>
> Where would you put it?
A single function in the sys module.
>
>> Rather than usi
On Dec 11, 2010, at 9:21 AM, Nick Coghlan wrote:
> On Sun, Dec 12, 2010 at 12:17 AM, Antoine Pitrou wrote:
>> On Sat, 11 Dec 2010 12:55:25 +1000
>> Nick Coghlan wrote:
>>
>>> On Sat, Dec 11, 2010 at 12:44 PM, Terry Reedy wrote:
On 12/10/2010 4:59 PM, R. David Murray wrote:
> Li
On Dec 13, 2010, at 1:21 PM, Terry Reedy wrote:
> Same here. A strong +1 for a consistent rule (always or never allowed) with a
> +1 for always given others use case of one param/arg per line.
It seems to me that a trailing comma in an argument list is more likely to be a
user error than a d
On Dec 13, 2010, at 2:16 PM, Guido van Rossum wrote:
> On Mon, Dec 13, 2010 at 1:55 PM, Raymond Hettinger
> wrote:
>>
>> It seems to me that a trailing comma in an argument list is more likely to
>> be a user error than a deliberate comma-for-the-future.
>
>
On Dec 14, 2010, at 3:38 AM, Fred Drake wrote:
> On Tue, Dec 14, 2010 at 6:24 AM, Steven D'Aprano wrote:
>> The good thing about that idea is that maintenance of buggy.py will be so
>> simple!
>
> It's self-describing, and needs no further documentation. :-)
>
And psychologically more effect
On Dec 19, 2010, at 10:41 AM, Guido van Rossum wrote:
> On Sun, Dec 19, 2010 at 5:13 AM, Antoine Pitrou wrote:
>> On Sat, 18 Dec 2010 20:23:49 -0800
>> Guido van Rossum wrote:
>>> I may be unique, but I fear there is no great answer. On the one hand
>>> I almost always code it as e.g. assertEqu
On Dec 24, 2010, at 10:56 AM, Terry Reedy wrote:
> On 12/24/2010 11:09 AM, Michael Foord wrote:
>> On 22/12/2010 02:26, Terry Reedy wrote:
>>> On 12/21/2010 7:17 AM, Michael Foord wrote:
>>>
>>> My first priority is that doc and code match.
>>> Close second is consistency (hence, ease of learnin
On Dec 25, 2010, at 2:59 AM, Stefan Behnel wrote:
> Hrvoje Niksic, 24.12.2010 09:45:
>> On 12/23/2010 10:03 PM, Laurens Van Houtven wrote:
>>> On Thu, Dec 23, 2010 at 9:51 PM, Georg Brandl wrote:
Yes and no -- there may not be an ambiguity to the parser, but still to
the human. Except i
On Jan 4, 2011, at 4:36 PM, Brett Cannon wrote:
> For those of you who don't know, the PSF has given me a two month
> grant to work on the core. It's mostly focused on the long overdue
> overhaul of the dev docs (now being called the devguide) and writing a
> HOWTO on porting Python 2 code to Pyt
Can you please take a look at
http://docs.python.org/dev/whatsnew/3.2.html#pep--python-web-server-gateway-interface-v1-0-1
to see if it accurately recaps the resolution of the WSGI text/bytes issues.
I would appreciate any feedback, as it is likely that the whatsnew
document will be most people
On Jan 22, 2011, at 11:04 AM, Terry Reedy wrote:
> The 3.x docs mostly started fresh with 3.0. The major exception is the What's
> new section, which goes back to 2.0. The 2.x stuff comprises about 650KB in
> the repository and whatever that translates into in the distribution. I
> cannot imag
Looking at http://docs.python.org/dev/library/html.html#module-html it would
appear that we've created a new module with a single trivial function.
In reality, there was already a python package, html, that served to group two
loosely related modules, html.parser and html.entities.
ISTM, that i
Right now, the tests for the unittest package are under the package directory
instead of Lib/test where we have most of the other tests.
There are some other packages that do the same thing, each for their own reason.
I think we should develop a strong preference for tests going under Lib/test
On Jan 24, 2011, at 3:40 PM, Michael Foord wrote:
> It isn't just unittest, it seems that all *test packages* are in their
> respective package and not Lib/test except for the json module where Raymond
> already moved the tests:
>
>distutils/tests
>email/test
>ctypes/test
>impor
On Jan 28, 2011, at 10:09 AM, Brett Cannon wrote:
> On Thu, Jan 27, 2011 at 20:55, Eli Bendersky wrote:
>> I'm working on improving the .rst documentation of test.support (Issue
>> 11015), and came upon the undocumented "fcmp" function that's being
>> exported from test.support, along with a "FU
On Jan 28, 2011, at 11:21 AM, Michael Foord wrote:
> On 28/01/2011 16:29, Brian Curtin wrote:
>>
>> Recently I've talked to two Python trainers/educators and the major gripe
>> their attendees see is that you can't just sit down and type "python" and
>> have something work. For multi-Python in
On Jan 30, 2011, at 8:21 PM, eli.bendersky wrote:
Please use the open tracker item and do not edit the document directly.
Raymond
___
Python-Dev mailing list
Python-Dev@python.org
http://mail.python.org/mailman/listinfo/python-dev
Unsubscribe:
http
On Feb 16, 2011, at 2:39 PM, Nick Coghlan wrote:
> On Thu, Feb 17, 2011 at 5:05 AM, Barry Warsaw wrote:
>> On Feb 16, 2011, at 12:34 PM, Terry Reedy wrote:
>>
>>> I would like the next release called 3.2.0 rather than just 3.2.
>>
>> +1
>>
>> (I'd have said +0 for the humor of it :).
>
> +0
On Feb 22, 2011, at 5:43 PM, Nick Coghlan wrote:
> On Tue, Feb 15, 2011 at 6:30 PM, "Martin v. Löwis" wrote:
>> I'm going to perform a Debian upgrade of svn.python.org on Friday,
>> between 9:00 UTC and 11:00 UTC. I'll be disabling write access during
>> that time. The outage shouldn't be longer
On Feb 24, 2011, at 4:19 PM, Antoine Pitrou wrote:
> Georg and I have been working on converting the SVN repository to
> Mercurial. We can now present you a test repository (actually, two).
>
>
> CPython repository: http://hg.python.org/cpython/
Thank you both for all the effort you put in.
I'
On Feb 25, 2011, at 12:09 AM, Martin v. Löwis wrote:
> I think I would have liked the strategy of the PEP better (i.e.
> create clones for feature branches, rather than putting all
> in a single repository).
In my brief tests, the single repository has been easy to work with.
If they were separa
On Feb 26, 2011, at 4:09 PM, Antoine Pitrou wrote:
> On Sat, 26 Feb 2011 10:09:33 +0100
> Hagen Fürstenau wrote:
>>
>> I just hunted down a change in behaviour between Python 3.1 and 3.2 to
>> possibly changed iteration order of sets due to the optimization in
>> issue #8685. Of course, this or
On Feb 28, 2011, at 12:07 PM, Georg Brandl wrote:
> On 28.02.2011 20:58, Antoine Pitrou wrote:
>> Le lundi 28 février 2011 à 13:56 -0600, Benjamin Peterson a écrit :
>>> 2011/2/28 Antoine Pitrou :
On Mon, 28 Feb 2011 13:36:11 -0500
Terry Reedy wrote:
>
>> + an existing branch
On Mar 3, 2011, at 4:40 AM, anatoly techtonik wrote:
> How about official RoadMap? There is no visibility into what's going
> on in Python development. New people can' t jump in and help do bring
> some features faster. http://dungeonhack.sourceforge.net/Roadmap
Thanks for the link. Their roadm
On Mar 5, 2011, at 8:44 AM, Antoine Pitrou wrote:
> On Sat, 5 Mar 2011 08:36:04 -0800
> Daniel Stutzbach wrote:
>
>> On Sat, Mar 5, 2011 at 5:54 AM, Tim Delaney
>> wrote:
>>
>>> If those were to be removed from .hgignore then there would be a high
>>> likelihood of someone doing "hg addremove
Today, there was a significant check-in to the peephole optimizer that I think
should be reverted:
http://hg.python.org/cpython/rev/14205d0fee45/
The peephole optimizer pre-dated the introduction of the abstract syntax tree.
Now that we have an AST, the preferred way to implement
On Mar 11, 2011, at 11:11 PM, Eugene Toder wrote:
> Experience shows that optimizations are always error prone, no matter
> what framework or internal representation you use.
On that basis, I believe that we ought to declare peephole.c as being
somewhat off-limits for further development (except
There are separate social, strategic, and tactical questions.
The social question: if the person who designed, implemented, and maintained
the optimizer recommends against a patch and another committer just checks it
in anyway, do we care? I've taken responsibility for this code and have
trea
I would like to withdraw my suggestion for the recursive constant folding patch
to be reverted. I value social harmony much more than a decision about whether
a particular patch is a good idea. I apologize to anyone who is upset over the
discussion.
Raymond
__
On Mar 12, 2011, at 3:44 PM, Guido van Rossum wrote:
> I was just reminded that in Python 3, list.sort() and sorted() no
> longer support the cmp (comparator) function argument. The reason is
> that the key function argument is always better. But now I have a
> nagging doubt about this:
>
> I re
On Mar 13, 2011, at 7:41 PM, Tim Lesher wrote:
> [I mentioned this to Raymond Hettinger after his PyCon talk, and I
> promised a bug and hopefully a patch. I don't see an obvious solution,
> though, so I'll ask here first.]
Just make a tracker entry and assign it to me.
I
One of simplest and least invasive ways to get help()
to show the underscore methods and attributes is to
make pydoc aware of named tuples by checking for the
presence of _fields.
* That leaves the named tuple code as simple as possible
(which is important because the self-documenting code
is e
On Mar 16, 2011, at 11:33 AM, R. David Murray wrote:
> On Wed, 16 Mar 2011 13:33:20 -0400, Michael Foord
> wrote:
>> On 16/03/2011 12:39, Alexander Belopolsky wrote:
>>> I was editing the turtle module (for issue11571, if you are
>>> interested) when I noticed that it has the following line:
>>
On Mar 16, 2011, at 12:36 PM, Thomas Heller wrote:
> I would like my committer rights to be retracted.
>
> I have been contributing to Python here and there for 10 years now,
> and it was a pleasant experience.
>
> Unfortunately, since about a year I have lots more things to do, and
> I won't b
I think devguide's suggested interbranch workflow introduces too much
complexity for too little payoff.
If I need to make a fix to 3.2, I can't just fix it. I would need to also
merge the changeset into 3.3 and then revert it, and then commit both. There
is not much payoff to this style. It
On Mar 17, 2011, at 12:22 PM, Eric Smith wrote:
> On 03/17/2011 03:08 PM, Jesus Cea wrote:
>> I would suggest to keep deprecating things in 3.x, BUT keeping the
>> deprecated stuff around (maybe reimplementing them using the new stuff)
>> until we decide is safe to axe it, instead of the regular
On Mar 19, 2011, at 11:21 AM, Antoine Pitrou wrote:
> On Sat, 19 Mar 2011 09:25:07 -0500
> s...@pobox.com wrote:
>
>> The dev guide says something about collapsing changesets. Is that
>> collapsing commits within a changeset or collapsing multiple changesets
>> (whatever that might be)? Do I n
On Mar 21, 2011, at 8:25 AM, Barry Warsaw wrote:
>
> Does Mercurial have a way of acting like a centralized vcs to the end user,
> the way Bazaar does? IOW, if Skip or others were more comfortable with a
> centralized workflow (which is entirely valid imo), can they set up their
> local workspac
On Mar 21, 2011, at 11:56 AM, Daniel Stutzbach wrote:
>
> People love it because it's a very powerful tool. People hate it because it
> allows you to shoot yourself in the foot.
There's a certain irony in this. The original motivation for version control
was to be a safety rope, to serve as
On Mar 28, 2011, at 12:38 AM, Daniel Stutzbach wrote:
> On Sun, Mar 27, 2011 at 10:53 PM, Nick Coghlan wrote:
> On Mon, Mar 28, 2011 at 2:11 PM, Daniel Stutzbach
> wrote:
> > Is there a good use-case for the func argument?
>
> The examples that Raymond gives in the docs (cumulative
> multipl
On Mar 30, 2011, at 2:35 PM, Terry Reedy wrote:
> The tracker was recently changed so that when I click on a link to a tracker
> page, the page is properly displayed, but then a fraction of a second it
> blinks and redisplays with the edit form hidden. This is so obnoxious to me
> that I no lo
The Hg source viewer needs to be tweaked to improve its usability.
What we've got now is a step backwards from the previous svn viewer.
Looking at http://hg.python.org/cpython/file/default/Lib/linecache.py for
example,
there are two issues. 1) the code cannot be cut-and-pasted because the
line
On Mar 31, 2011, at 9:52 AM, Terry Reedy wrote:
> I would like to try putting the comment box after the last (most recent)
> comment, as that is the message one most ofter responds to. Having to now
> scroll up and down between comment box and last message(s) is often of a
> nuisance.
While t
On Mar 31, 2011, at 5:02 PM, Westley Martínez wrote:
>
> How 'bout no? YouTube uses this and it's horrid and unnatural, and
> bulletin boards have been using chronological order for whiles with
> great success. Reverse chronological order has a niche for feeds,
> updates, whatever you want to cal
On Mar 31, 2011, at 5:30 PM, Antoine Pitrou wrote:
> On Thu, 31 Mar 2011 16:15:48 -0700
> Raymond Hettinger wrote:
>> The Hg source viewer needs to be tweaked to improve its usability.
>> What we've got now is a step backwards from the previous svn viewer.
>>
>&
On Mar 31, 2011, at 5:55 PM, Antoine Pitrou wrote:
> Le jeudi 31 mars 2011 à 17:46 -0700, Raymond Hettinger a écrit :
>> On Mar 31, 2011, at 5:30 PM, Antoine Pitrou wrote:
>>
>>> On Thu, 31 Mar 2011 16:15:48 -0700
>>> Raymond Hettinger wrote:
>>>>
On Mar 31, 2011, at 6:28 PM, Victor Stinner wrote:
> Le 01/04/2011 01:15, Raymond Hettinger a écrit :
>> The Hg source viewer needs to be tweaked to improve its usability.
>> What we've got now is a step backwards from the previous svn viewer.
>>
>> Looking at h
On Apr 1, 2011, at 12:40 PM, Martin v. Löwis wrote:
>> That's *way* better:
>>
>> https://bitbucket.org/mirror/cpython/src/3558eecd84f0/Lib/linecache.py
>>
>> Why can't we have that for our primary source viewer.
>
> Would you like to install this, or something else, or change the
> templates
[Brett]
> This PEP requires that in these instances that both
> the Python and C code must be semantically identical
Are you talking about the guaranteed semantics
promised by the docs or are you talking about
every possible implementation detail?
ISTM that even with pure python code, we get prob
On Apr 6, 2011, at 10:24 AM, Maciej Fijalkowski wrote:
>
> "I saw no need to complicate the pure python code for this."
>
> if you complicate the C code for this, then please as well complicate
> python code for this since it's breaking stuff.
Do you really need a PEP for this one extraordinar
On Apr 6, 2011, at 10:39 AM, Brett Cannon wrote:
> Since people are taking my "semantically identical" point too strongly for
> what I mean (there is a reason I said "except in cases
> where implementation details of a VM prevents [semantic equivalency]
> entirely"), how about we change the requ
On Apr 6, 2011, at 1:22 PM, Brett Cannon wrote:
>
>
> On Wed, Apr 6, 2011 at 12:45, Raymond Hettinger
> wrote:
>
> On Apr 6, 2011, at 10:39 AM, Brett Cannon wrote:
> > Since people are taking my "semantically identical" point too strongly for
> &g
On Apr 6, 2011, at 1:22 PM, Brett Cannon wrote:
> How about the test suite needs to have 100% test coverage (or as close as
> possible) on the pure Python version? That will guarantee that the C code
> which passes that level of test detail is as semantically equivalent as
> possible. It also
On Apr 6, 2011, at 2:40 PM, Antoine Pitrou wrote:
> For the record, I've tried to make the force build form clearer on the
> buildbot Web UI. See e.g.:
> http://www.python.org/dev/buildbot/all/builders/x86%20OpenIndiana%20custom
Much improved. Thanks.
Raymond
___
On Apr 7, 2011, at 9:22 AM, anatoly techtonik wrote:
> On Thu, Apr 7, 2011 at 7:01 AM, Benjamin Peterson wrote:
>> 2011/4/6 anatoly techtonik :
>>> Is it a good idea to have code highlighting in tracker?
+0
That has its highpoints;
* give tracker entries a more professional appearance
close
On Apr 13, 2011, at 4:52 AM, Antoine Pitrou wrote:
> On Wed, 13 Apr 2011 06:28:58 +0200
> Stefan Behnel wrote:
>>
>> However, I think we are really discussing a theoretical issue here. All the
>> PEP is trying to achieve is to raise the bar for C code in the stdlib, for
>> exactly the reason
On Apr 14, 2011, at 8:34 AM, P.J. Eby wrote:
> At 03:55 PM 4/14/2011 +0100, Michael Foord wrote:
>> Ricardo isn't suggesting that Python should always call super for you, but
>> when you *start* the chain by calling super then Python could ensure that
>> all the methods are called for you. If a
On Apr 14, 2011, at 12:22 PM, Sandro Tosi wrote:
> The version we have in cpython of json is simplejson 2.0.9 highly
> patched (either because it was converted to py3k, and because of the
> normal flow of issues/bugfixes) while upstream have already released
> 2.1.13 .
>
> Their 2 roads had dive
On Apr 14, 2011, at 3:32 PM, Ricardo Kirkner wrote:
>>
>> What would the semantics be of a super that intentially calls all siblings?
>> In particular what is the return value of such a call? The implementation
>> can't know how to combine the implementations in the inheritance chain and
>> s
On Apr 16, 2011, at 2:45 PM, Brett Cannon wrote:
>
>
> On Sat, Apr 16, 2011 at 14:23, Stefan Krah wrote:
> Brett Cannon wrote:
> > In the grand python-dev tradition of "silence means acceptance", I consider
> > this PEP finalized and implicitly accepted.
I haven't seen any responses that sai
In the grand python-dev tradition of "silence means acceptance", I consider
this PEP finalized and implicitly accepted.
>>
>> I haven't seen any responses that said, yes this is a well thought-out
>> proposal
>> that will actually benefit any of the various implementations.
>
> In tha
On Apr 18, 2011, at 10:11 AM, Maciej Fijalkowski wrote:
>
> * we usually target CPython version that's already frozen, which is
> pretty inconvinient to post this changes back. Example would be a
> socket module where it has changed enough in 3.x that 2.7 changes make
> no sense.
Do you have an
On Apr 25, 2011, at 11:43 AM, cool-RR wrote:
> Today I was trying to use `total_ordering` for the first time. I was
> expecting that in order to implement e.g. `x > y` it would do `not x < y and
> not x == y`, assuming that `__lt__` and `__eq__` are defined.
This was fixed. The current code
On Apr 27, 2011, at 2:37 AM, Hrvoje Niksic wrote:
> The other day I was surprised to learn this:
>
> >>> nan = float('nan')
> >>> nan == nan
> False
> >>> [nan] == [nan]
> True # also True in tuples, dicts, etc.
Would also be surprised if you put an object in a dictionary but c
On Apr 27, 2011, at 7:53 AM, Guido van Rossum wrote:
> Maybe we should just call off the odd NaN comparison behavior?
I'm reluctant to suggest changing such enshrined behavior.
ISTM, the current state of affairs is reasonable.
Exotic objects are allowed to generate exotic behaviors
but consum
On Apr 27, 2011, at 10:16 AM, Alexander Belopolsky wrote:
> Unfortunately NaNs are not that exotic.
They're exotic in the sense that they have the unusual property of not being
equal to themselves.
Exotic (adj) strikingly strange or unusual
Raymond
ISTM there is no right or wrong answer.
There is just a question of what is most useful.
AFAICT, the code for dictionaries (and therefore the code for sets)
has always had identity-implies-equality logic. It makes dicts
blindingly fast for common cases. It also confers some nice
properties like
On Apr 28, 2011, at 1:27 PM, Holger Krekel wrote:
> On Thu, Apr 28, 2011 at 6:59 PM, Guido van Rossum wrote:
>> On Thu, Apr 28, 2011 at 12:54 AM, Tarek Ziadé wrote:
>>> In my opinion assert should be avoided completely anywhere else than
>>> in the tests. If this is a wrong statement, please le
On Apr 28, 2011, at 3:07 PM, Guido van Rossum wrote:
> On Thu, Apr 28, 2011 at 2:53 PM, Raymond Hettinger
> wrote:
>>
>> On Apr 28, 2011, at 1:27 PM, Holger Krekel wrote:
>>
>>> On Thu, Apr 28, 2011 at 6:59 PM, Guido van Rossum wrote:
>>>>
On May 1, 2011, at 10:57 AM, Georg Brandl wrote:
> I'd like to release Python 3.2.1 on May 21, with a release candidate
> on May 14. Please bring any issues you think need to be fixed in it
> to my attention by assigning "release blocker" status in the tracker.
Thanks to http://www.python.org/
On May 5, 2011, at 10:18 AM, Guido van Rossum wrote:
> On Thu, May 5, 2011 at 10:17 AM, Amaury Forgeot d'Arc
> wrote:
>> 2011/5/5 Guido van Rossum :
>>> Seems you're in agreement with this. IMO when references are borrowed
>>> it is not very interesting. The interesting thing is when calling a
>
On May 5, 2011, at 11:41 AM, Benjamin Peterson wrote:
> 2011/5/5 raymond.hettinger :
>> http://hg.python.org/cpython/rev/1a56775c6e54
>> changeset: 69857:1a56775c6e54
>> branch: 3.2
>> parent: 69855:97a4855202b8
>> user:Raymond Hettinger
&g
On May 17, 2011, at 5:27 PM, Ethan Furman wrote:
> The bytes type in Python 3 does not feel very consistent.
>
> For example:
>
> --> some_var = 'abcdef'
> --> some_var
> 'abcdef'
> --> some_var[3]
> 'd'
> --> some_other_var = b'abcdef'
> --> some_other_var
> b'abcdef'
> --> some_other_var[3]
>
On May 19, 2011, at 7:40 PM, Ethan Furman wrote:
> Several folk have said that objects that compare equal must hash equal...
And so do the docs:
http://docs.python.org/dev/reference/datamodel.html#object.__hash__
, "the only required property is that objects which compare equal have the same
On Jun 3, 2011, at 10:27 AM, eric.araujo wrote:
>
> Fix reST label for collections ABCs.
>
> The previous markup hijacked the abstract-base-classes glossary entry,
> which resulted in the HTML linking to collections.abc when defining the
> generic ABC concept. Now the glossary links to the abc
> On Jun 4, 2011, at 11:32 PM, Martin v. Löwis wrote:
>
>> b) telling people to use Twisted or asyncore on the server side
>> if they are new to sockets is bad advice. People *first* have
>> to understand sockets, and *then* can use these libraries
>> and frameworks. Those libraries aren't
On Jun 12, 2011, at 8:29 AM, Lukas Lueg wrote:
> Hi.
>
> We extensively use the struct module to crunch large amounts of binary
> data. There are basically two operations for us that only seem to the
> naked eye as one: Filtering (see if certain fields have certain
> values, throw everything awa
On Jun 12, 2011, at 3:18 PM, Greg Ewing wrote:
> Raymond Hettinger wrote:
>
>> The problem you're trying to solve isn't unique to structs.
>> That's why we get periodic requests for ropes-like behaviors
>
> I don't think he's asking for rope
On Jun 30, 2011, at 2:14 AM, Ezio Melotti wrote:
> Hi,
>
> On Thu, Jun 30, 2011 at 2:51 AM, raymond.hettinger
> wrote:
> Fixup repr for dict_proxy objects.
>
>
> This was already fixed in a slightly different way in 3.x.
The %R formatting code is not available in 2.x
Raymond_
On Jul 20, 2011, at 3:16 PM, Brett Cannon wrote:
>
>
> On Wed, Jul 20, 2011 at 11:48, Terry Reedy wrote:
> On 7/20/2011 12:25 PM, Victor Stinner wrote:
> Le 20/07/2011 17:58, Éric Araujo a écrit :
> Do we have a policy of not adding new test files to stable branches?
> New logging tests failed
Please don't add the IRC link to the devguide.
Based on conversations with Guido, he is against it being part of the core
development process.
Raymond
On Jul 21, 2011, at 4:08 AM, Nick Coghlan wrote:
> On Thu, Jul 21, 2011 at 7:16 PM, Ezio Melotti wrote:
>>
>> FWIW you can make #python a
On Jul 23, 2011, at 5:18 PM, Antoine Pitrou wrote:
>
> My point is that on non-trivial benchmarks, the savings are almost zero.
That could be said of any optimization in Python.
Typical Python scripts exercise many features at time,
so any one optimization by itself if almost useless.
Collective
> - If you make a mistake in LaTeX, you will get a cryptic error which
> is usually a little difficult to figure out (if you're not used to
> it). You can an error though.
FWIW, the pure Python program in Tools/scripts/texchecker.py does a
pretty good job of catching typical LaTeX mistakes and
> - If you make a mistake in LaTeX, you will get a cryptic error which
> is usually a little difficult to figure out (if you're not used to
> it). You can an error though.
FWIW, the pure Python program in Tools/scripts/texchecker.py does a
pretty good job of catching typical LaTeX mistakes and
> - If you make a mistake in LaTeX, you will get a cryptic error which
> is usually a little difficult to figure out (if you're not used to
> it). You can an error though.
FWIW, the pure Python program in Tools/scripts/texchecker.py does a
pretty good job of catching typical LaTeX mistakes and
> - If you make a mistake in LaTeX, you will get a cryptic error which
> is usually a little difficult to figure out (if you're not used to
> it). You can an error though.
FWIW, the pure Python program in Tools/scripts/texchecker.py does a
pretty good job of catching typical LaTeX mistakes and
> - If you make a mistake in LaTeX, you will get a cryptic error which
> is usually a little difficult to figure out (if you're not used to
> it). You can an error though.
FWIW, the pure Python program in Tools/scripts/texchecker.py does a
pretty good job of catching typical LaTeX mistakes and
From: "Greg Ewing"
> If the aforementioned iterable can yield *anything*,
> then it might yield this 'nodef' value as well.
>
> For this reason, there *can't* exist any *standard*
> guaranteed-unambiguous sentinel value. Each use
> case needs its own, to ensure it's truly unambiguous
> in the con
[Walter Dörwald]
> I'd like to propose the following addition to itertools: A function
> itertools.getitem() which is basically equivalent to the following
> python code:
>
> _default = object()
>
> def getitem(iterable, index, default=_default):
>try:
> return list(iterable)[index]
>
From: "Guido van Rossum" <[EMAIL PROTECTED]>
> But doesn't the very same argument also apply against islice(), which
> you just offered as an alternative?
Not really. The use cases for islice() typically do not involve
repeated slices of an iterator unless it is slicing off the front
few elements
[Matthieu on itertools.dropwhile() docs]
> Make an iterator that drops elements from the iterable as long as the
> predicate is true; afterwards, returns every element. Note,
> the iterator does not produce any output until the predicate is true, so it
> may have a lengthy start-up time.
>
> It
601 - 700 of 1487 matches
Mail list logo
