Where I cut your words, we are in 100% agreement. (FWIW :-)
Guido van Rossum writes:
> On Tue, Aug 30, 2011 at 11:03 PM, Stephen J. Turnbull
> wrote:
> > Well, that's why I wrote "intended to be suggestive". The Unicode
> > Standard does not specify at all
Glenn Linderman writes:
> We can either artificially constrain ourselves to minor tweaks of
> the legal conforming bytestreams,
It's not artificial. Having the internal representation be the same
as a standard encoding is very useful for a large number of minor
usages (urgently saving buffers
Glenn Linderman writes:
> I found your discussion of streams versus arrays, as separate concepts
> related to Unicode, along with Terry's bisect indexing implementation,
> to rather inspiring. Just because Unicode defines streams of codeunits
> of various sizes (UTF-8, UTF-16, UTF-32) to r
Glenn Linderman writes:
> How many different iterators into the same text would be concurrently
> needed by an application? And why?
A WYSIWYG editor for structured text (TeX, HTML) might want two (at
least), one for the "source" window and one for the "rendered" window.
One might want to sav
Glenn Linderman writes:
> Windows 7 64-bit on one of my computers happily crashes several
> times a day when it detects inconsistent internal state... under
> the theory, I guess, that losing work is better than saving bad
> work. You sound the opposite.
Definitely. Windows apps habitually
Guido van Rossum writes:
> On Thu, Sep 1, 2011 at 12:13 AM, Stephen J. Turnbull
> wrote:
> > while at least this Spanish-as-a-second-language learner was taught
> > that `ñ' is an atomic character represented by a discontiguous glyph,
> > like `i', and it
Tres Seaver writes:
> FWIW, I was taught that Spanish had 30 letters in the alfabeto: the
> 'ñ', plus 'ch', 'll', and 'rr' were all considered distinct characters.
That was always a Castellano vs. Americano issue, IIRC. As I wrote,
Mr. Gonzalez was Castellano.
I believe that the deprecation
Greg Ewing writes:
> I find it curious that pronunciation always seems to take
> precedence over spelling in campaigns like this. Nowadays,
> especially with the internet increasingly taking over from
> personal interaction, we probably see words written a lot
> more often than we hear them s
Joao S. O. Bueno writes:
> Removing it would mean explicitly "batteries removal".
That's what we usually do with a dead battery, no?
___
Python-Dev mailing list
Python-Dev@python.org
http://mail.python.org/mailman/listinfo/python-dev
Unsubscribe:
http
Nick Coghlan writes:
> However, a big +1 for deprecation in the case of bytes and bytearray.
> That's nothing to do with the maintenance burden though, it's to do
> with the semantic confusion between binary data and ASCII-encoded text
> implied by the retention of methods like upper(), lower(
Antoine Pitrou writes:
> Bytes objects are often used for partly ASCII strings,
All I can say to that phrase is, "urk, ISO 2022 anyone?"
> not arbitrary "arrays of bytes". And making indexing of bytes
> objects return ints was IMHO a mistake.
Bytes objects are not ASCII strings, even though
This is all speculation and no hint of implementation at this point ...
redirecting this subthread to Python-Ideas. Reply-To set accordingly.
Nick Coghlan writes:
> Heh, I knew as soon as I sent that message that someone would be able
> to point out a counter example. I agree that RFC 822 (and
Antoine Pitrou writes:
> You could also point out UTF-16 or EBCDIC, but I fail to see how that's
> relevant. Do you have problems with ISO 2022 when parsing, say, e-mail
> headers?
Yes, of course! Especially when it's say, packed EUC not encapsulated
in MIME words. I think Mailman now handle
Glyph Lefkowitz writes:
> On Sep 7, 2011, at 10:26 AM, Stephen J. Turnbull wrote:
>
> > How about "title"?
>
> >>> 'content-length'.title()
> 'Content-Length'
>
> You might say that the protocol "has" to be
Georg Brandl writes:
> I don't think so. "skip if not" reads pretty well for me, while I
> always have to think twice about "unless" -- may be a non-native-
> speaker thing.
FWIW, speaking as one native speaker, I'm not sure about that. "do ...
if not condition" doesn't bother me, whether I t
Ethan Furman writes:
> Well, actually, I'd be using it with dates. ;)
Why are you representing dates with floats?
(That's a rhetorical question, don't answer it.)
This is the whole problem with this discussion. Guido is saying (and
I think it's plausible though I don't have enough experience
Antoine Pitrou writes:
> StringIO is an in-memory file-like object, like in 2.x (where it lived
> in the "cStringIO" module). I don't think it's a novel thing.
The problem is the name "StringIO". Something like "StringStream" or
"StringBuffer" might be more discoverable. I personally didn't h
Antoine Pitrou writes:
> I'm not sure why "StringStream" or "StringBuffer" would be more
> discoverable, unless you're coming from a language where these names are
> well-known.
I think they are, but it doesn't really matter, since both are a bit
lame, and I doubt either is sufficiently sugges
"Martin v. Löwis" writes:
> > Also, could I remind you that a better commit message is probably
> > "make PyUnicode_FromKindAndData raise a ValueError if the kind is
> > unknown".
>
> I think this is asking too much.
This distinction is important enough that it's worth asking non-native
spe
"Martin v. Löwis" writes:
[Terry Reedy wrote:]
> > Is it both technically possible (with hg) and socially permissible (with
> > us) to edit another's commit message?
>
> It's not technically possible,
Currently, in hg. git has a mechanism for adding notes which are
automatically displayed
Cameron Simpson writes:
> Am I really the only person who feels unease about this scenario?
No, you are not alone.
Though in practice with all the "Welcome, Cracker!" boxes out there,
one more less-secure-than-it-could-be VM probably doesn't matter all
that much. More important to Python is Te
Éric Araujo writes:
> Le 04/10/2011 04:59, Stephen J. Turnbull a écrit :
> > I'm not familiar with the hg dev process (I use hg a lot, but so far
> > it Just Works for me :), but I would imagine they will move in that
> > direction as well.
"That direction&quo
Andrew Bennetts writes:
> No, that just means you shouldn't trust *root*. Which is where a
> VM is a very useful tool. You can have the “as root” environment
> for your tests without the need to have anything important trust it.
Cameron acknowledges that he missed that. So maybe he was righ
Glyph writes:
> Have I left anything out? :-)
Probably. That's the nature of the problem. But you caught enough
that if all our buildbots are set up that way, the Bad Guys' scripts
will probably conclude there's nothing to see here, and move along.
_
Victor Stinner writes:
> I propose to raise Unicode errors if a filename cannot be decoded
> on Windows, instead of creating a bogus filenames with questions
> marks.
By "bogus" you mean "sometimes (?) invalid and the OS will refuse to
use them, causing a later hard-to-diagnose exception", rat
In general I agree with what you write, Terry. One clarification and
one comment, though.
Terry Reedy writes:
> The doc says "All functions accepting path or file names accept both
> bytes and string objects, and result in an object of the same type, if a
> path or file name is returned." I
"Martin v. Löwis" writes:
> > Therefore, as you imply, I think the solution to this issue is to start
> > the process of deprecating the bytes version of the api in py3k with a
> > view to removing it completely
> That sounds all fine to me.
As quoted above, deprecation of the bytes version
Carl Meyer writes:
> > On 31 October 2011 16:08, Tres Seaver wrote:
> >> I would say this is a perfect "opportunity to delegate," in this case
> >> to the devotees of other cults^Wshells than bash.
>
> Good call - we'll stick with what we've got until such devotees
> show up :-)
That's fi
Jesus Cea writes:
> A bit of discipline and, voila, automatic flawless merges! :-)
Doesn't work that way, sorry. The discipline required is isomorphic to
that required by threaded programs. See multiple threads on
python-ideas for why that is less than automatic or flawless. :-)
Antoine's sugg
Eli Bendersky writes:
> special locale. It makes me wonder whether it's possible to have a
> contradiction in the ordering, i.e. have a set of names that just
> can't be sorted in any order acceptable by everyone.
Yes, it is. The examples were already given in this thread. The
Han-using lang
Xavier Morel writes:
> On 2011-11-12, at 10:24 , Georg Brandl wrote:
> > Am 12.11.2011 08:03, schrieb Stephen J. Turnbull:
> >> The sensible thing is to just sort in Unicode code point order, I
> >> think.
> > The sensible thing is to accept that
Barry Warsaw writes:
> Hopefully, we're going to be making a dent in that in the next version of
> Ubuntu.
This is still a big mess in Gentoo and MacPorts, though. MacPorts
hasn't done anything about ceating a transition infrastructure AFAICT.
Gentoo has its "eselect python set VERSION" stuff,
Xavier Morel writes:
> On 2011-11-22, at 17:41 , Stephen J. Turnbull wrote:
> > Barry Warsaw writes:
> >> Hopefully, we're going to be making a dent in that in the next version of
> >> Ubuntu.
> > This is still a big mess in Gentoo and MacPorts, thoug
Antoine Pitrou writes:
> On Tue, 22 Nov 2011 20:27:24 -0800
> Raymond Hettinger wrote:
> > >
> > > But look! I'm already practicing: NO YOU CAN'T CHECK THAT IN. How's
> > > that? Needs work?
> >
> > You could try a more positive leadership style: THAT LOOKS GREAT, I'M
> > SURE THE
Dirkjan Ochtman writes:
> On Tue, Nov 22, 2011 at 17:41, Stephen J. Turnbull
> wrote:
> > This is still a big mess in Gentoo and MacPorts, though. MacPorts
> > hasn't done anything about ceating a transition infrastructure AFAICT.
> > Gentoo has its "esel
Ned Deily writes:
> In article <87fwhfqywr@uwakimon.sk.tsukuba.ac.jp>,
> "Stephen J. Turnbull" wrote:
> > I haven't had the nerve to do this on MacPorts because "port" is such
> > a flaky thing (not so much port itself, but so many p
Dirkjan Ochtman writes:
> I'm sorry for the lack of response in the past. I looked at Gentoo's
> Bugzilla and didn't find any related bugs you reported or were CC'ed
> on, can you name some of them?
This isn't about my bugs; I've been able to work through them
satisfactorily. It's about what
Nick Coghlan writes:
> I'll stick with named branches until MQ becomes a builtin Hg
> feature that better integrates with other tools.
AFAIK MQ *is* considered to be a *stable, standard* part of Hg
functionality that *happens* (for several reasons *not* including
"it's not ready for Prime Time"
Matt Joiner writes:
> This is a great argument. But people want to see new, bigger better
> things in the standard library, and the #1 reason cited against this
> is "we already have too much". I think that's where the issue lies:
> Either lots of cool nice stuff is added and supported (we all
Antoine Pitrou writes:
> Actually, we don't often get patches for new features. Many new
> features are implemented by core developers themselves.
Right. That's not inconsistent with what I wrote, as long as would-be
feature submitters realize what the standards for an acceptable
feature patch
Georg Brandl writes:
> Oh, come on, surely this doesn't effect the casual reader?
Casual readers aren't effective in any case; you want to hear the
opinions of those who care.
___
Python-Dev mailing list
Python-Dev@python.org
http://mail.python.org/ma
Nick Coghlan writes:
> So, instead of attempting to paper over the problem by reintroducing
> u'', perhaps the discussion we should be having is whether or not PEP
> 's superficially appealing concept of defining an API in terms of
> "native strings" is a loser in practice,
+1
to that di
Chris McDonough writes:
> Given an effective choice between enabling six lines of code in Python
> 3.3 to support u'' and months of political wrangling and code rewriting,
> I'll choose the former any day.
Sure, but the real question is whether that *is* the effective choice.
Maybe the effecti
Fernando Perez writes:
> Apology for the advertising,
If there's any apologizing to be done, it's on Anatoly's part. Your
post was short, to the point, information-packed, and should put a big
fat open-centered ideographic full stop period to this thread.
__
anatoly techtonik writes:
> Fernando clearly showed that IPython rocks, because CPython suxx.
No, IPython rocks because it focuses on doing one thing well:
providing an interactive environment that takes advantage of the many
features that Python provides in support. CPython should do the sam
Victor Stinner writes:
> Let's try to summarize this "vulnerability".
>
> The creation of a Python dictionary has a complexity of O(n) in most
> cases, but O(n^2) in the *worst* case. The attack tries to go into the
> worst case. It requires to compute a set of N keys having the same hash
Christian Heimes writes:
> Am 31.12.2011 13:03, schrieb Stephen J. Turnbull:
> > I don't know the implementation issues well enough to claim it is a
> > solution, but this hasn't been mentioned before AFAICS:
> >
> > While the dictionary probe
Matt Joiner writes:
> Readability is the highest concern, and this should be at the
> discretion of the contributor.
That's quite backwards. "Readability" is community property, and has
as much, if not more, to do with common convention as with some
absolute metric. The "contributor's discret
Benjamin Peterson writes:
> Ethan Furman stoneleaf.us> writes:
> >
> > Readability also includes more than just the source code; as has already
> > been stated:
[diffs elided]
> > I find the diff version that already had braces in place much more
> > readable.
>
> There are much larg
Benjamin Peterson writes:
> My goodness, I was trying to make a ridiculous-sounding proposition.
In this kind of discussion, that's in the same class as "be careful
what you wish for -- because you might just get it."
___
Python-Dev mailing list
Python
Jack Diederich writes:
> On Thu, Jan 12, 2012 at 9:57 PM, Guido van Rossum wrote:
> > Hm... I started out as a big fan of the randomized hash, but thinking more
> > about it, I actually believe that the chances of some legitimate app having
> >>1000 collisions are way smaller than the chances
mar...@v.loewis.de writes:
> >> It doesn't change anything, you will still get collisions.
> >
> >
> > That depends right? If the collision is because they all have the same
> > hash(), yes. It might be different if it is because the secondary hashing
> > (or whatever it's called :-) causes c
Executive summary:
My take is "show us the additional resources, and don't be stingy!"
Sorry, Antoine, I agree with your goals, but I think you are too
optimistic about the positive effects and way too optimistic about the
costs.
Antoine Pitrou writes:
> Finding a release cycle for an open-sour
Antoine Pitrou writes:
> > Since testing is the bottleneck on what users consider to be
> > "available for me", you cannot decrease the amount of testing (alpha,
> > beta releases) by anywhere near the amount you're increasing
> > frequency, or you're just producing "as is" snapshots.
>
> T
Antoine Pitrou writes:
> 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 bugs in released software, which improves user
perception of stability, e
Nick Coghlan writes:
> >From the stdlib feature development branch (these are the new interim
> releases with standard library updates only as proposed by PEP 407):
> Python 3.3.1 + stdlib 13.02.0 (~February 2013)
> Python 3.3.2 + stdlib 13.08.0 (~August 2013)
> Python 3.3.3 + stdlib 14.02.
Georg Brandl writes:
> "The status quo really isn't all that bad" applies to any PEP. Also,
> compared to most PEPs, it is quite easy to revert to the previous
> state of things if they don't work out as wanted.
That depends on how "doesn't work out" plays out. If meeting the
schedule *and*
Steven D'Aprano writes:
> Pardon me, but people like Stephen Turnbull are *users* of Python, exactly
> the
> sort of people you DO have to convince that moving to an accelerated or more
> complex release process will result in a better product.
Well, to be fair, An
Ethan Furman writes:
> Where does one draw the line between feature and bug?
Bug: Doesn't work as documented.
Feature: Works as expected but not documented[1] to do so.
Miracle: Works as documented.[2]
Unspecified behavior that doesn't work as you expect is the unmarked
case (ie, none of
Benjamin Peterson writes:
> 2012/1/21 Stefan Krah :
> > Do you mean (void)write(...)? Many people think this is good practice,
> > since it indicates to the reader that the return value is deliberately
> > ignored.
>
> Not doing anything with it seems fairly deliberate to me.
It may be del
Lennart Regebro writes:
> On Mon, Jan 23, 2012 at 06:02, Paul McMillan wrote:
> >> We may use a different salt per dictionary.
> >
> > If we're willing to re-hash everything on a per-dictionary basis. That
> > doesn't seem reasonable given our existing usage.
>
> Well, if we get crazy amou
Michael Foord writes:
> >> Assuming the module is then promoted to the the standard library proper in
> >> release ``3.X+1``, it will be moved to a permanent location in the
> >> library::
> >>
> >> import example
> >>
> >> And importing it from ``__preview__`` will no longer work.
>
Executive summary:
If the promise to remove the module from __preview__ is credible (ie,
strictly kept), then __preview__ will have a specific audience in
those who want the stdlib candidate code and are willing to deal with
a certain amount of instability in that code.
(Whether that audience is
Eli Bendersky writes:
> My point is that if our users accept *this*, in the stable stdlib, I
> see no reason they won't accept the same happening between __preview__
> and a graduated module, when they (hopefully) understand the intention
> of __preview__.
If it doesn't happen with sufficient
Nick Coghlan writes:
> People need to remember there's another half to this equation: the
> core dev side.
Why? There's nothing about it in the PEP.
> The reason *regex* specifically isn't in the stdlib already is
> largely due to (perhaps excessive) concerns about the potential
> maintena
Nick Coghlan writes:
> 1. Draft ReStructuredText documentation for inclusion in the stdlib docs
>
> (still needed)
No wonder people (not directly involved in development of the module)
think that the proponents don't care! What good is a battery if the
odds are even that you will hook it
Victor Stinner writes:
> There is the same problem [that encode-decode with the 'locale'
> codec doesn't roundtrip reliably] with the filesystem encoding
> (sys.getfilesystemencoding()),
-1 on a query to the OS that pretends to be a constant.
You see, it's not the same problem. The differenc
Victor Stinner writes:
> > If this is needed, it should be spelled "os.getlocaleencoding()" (or
> > "sys.getlocaleencoding()"?)
>
> There is already a locale.getpreferredencoding(False) function which
> give your the current locale encoding. The problem is that the current
> locale encoding
A protagonist writes:
> -- Forwarded message --
> From: Fredrik Lundh
As a not-directly-concerned third party who's been lurking, it seems
to me like people are in way too much of a rush to "get things done".
Sending direct mail, addressing the precise question[1] seems to have
Eli Bendersky writes:
> Well, I think the situation is pretty good now.
I agree, but improvement is always possible.
> If one goes to python.org and is interested in contributing,
> clicking on the "Core Development" link is a sensible step, right?
Maybe. But a lot of the "Core Dev" links
Antoine Pitrou writes:
> I think the word "provisional" doesn't mean anything to many
> (non-native English speaking) people. I would like to suggest something
> clearer, e.g. "experimental" or "unstable" - which have the benefit of
> *already* having a meaning in other software-related contex
Steven D'Aprano writes:
> Also, "Czar" is commonly used in US politics as an informal term for the top
> official responsible for an area.
I think here the most important connotation is that in US parlance a
"czar" does not report to a committee, and with the exception of a
case where Sybil is
R. David Murray writes:
> If most people agree with Antoine I won't fight it, but it seems to me
> that accepting unicode in the binascii and base64 APIs is a bad
> idea.
First, I agree with David that this change should have been brought up
on python-dev before committing it. The distinction
Brett Cannon writes:
> I think that's inviting trouble if you can provide the seed. It leads to a
> false sense of security
I thought the point of providing the seed was for reproducability of
tests and the like?
As for "false sense", can't we document this and chalk up hubristic
behavior to "
Antoine Pitrou writes:
> How is it a "false sense of security" at all? It's the same as
> setting a private secret for e.g. session cookies in Web applications.
> As long as you don't leak the seed, it's (should be) secure.
That's true. The problem is, the precondition that you won't leak the
Brian Curtin writes:
> If you want to contribute to development, I think you'll know that a
> link about development is relevant.
For values of "you" in "experienced programmers", yes. But
translators and tech writers don't consider what they do to be
"development."
__
Brian Curtin writes:
> On Thu, Feb 23, 2012 at 01:15, Stephen J. Turnbull
> wrote:
> > Brian Curtin writes:
> >
> > > If you want to contribute to development, I think you'll know that a
> > > link about development is relevant.
> >
>
mar...@v.loewis.de writes:
> One thing that the PEP will certainly achieve is to spread the myth that
> you cannot port to Python 3 if you also want to support Python 2.5. That's
> because people will accept the "single source" approach as the one right way,
> and will accept that this only wo
Yury Selivanov writes:
> Otherwise, many of its points are moot, and we need to raise a
> question of rejecting it somehow.
Yury, that's not going to happen. Guido made it quite clear that he
agrees with those who consider this PEP useful, obvious, and safe, and
the PEP *is* approved. There h
Mark Janssen writes:
> Since there's no way (even theoretical way) to completely secure anything
> (remember the DVD protection wars?), there's no way there should be any
> liability if reasonable diligence is performed to provide security where
> expected (which is probably calculable to some
Chris McDonough writes:
> FWIW, I think this issue's webness may be overestimated. There happens
> to be lots and lots of existing UI code which contains complex
> interactions between unicode literals and nonliterals in web apps, but
> there's also likely lots of nonweb code that has the sam
On Tue, Mar 20, 2012 at 8:34 AM, Guido van Rossum wrote:
> Anyway, I also tried to imply that it matters if the number of list
> items would ever be huge. It seems that is indeed possible (even if
> not likely) so I think iterators are useful.
But according to Nick's post, there's some sort of u
Cleaning up the absurd CC line
On Thu, Mar 22, 2012 at 8:03 AM, Paul Moore wrote:
> I agree on all points here. I don't understand quite why backward
> compatibility is being treated so lightly here. But equally, I've made
> my points and have little further to add.
As a non-Windows user wh
On Thu, Mar 22, 2012 at 11:56 PM, Greg Ewing
wrote:
> Can we please get rid of the sidebar, or at least provide
> a way of turning it off? I don't think it's anywhere
> near useful enough to be worth the space it takes up.
+1. It seems to mostly duplicate the headline next/previous
buttons alrea
On Fri, Mar 23, 2012 at 2:37 PM, Paul Moore wrote:
> Another problem case: cx_Freeze. This currently breaks when installed
> in a viretualenv, as it locates the "Scripts" directory by appending
> "Scripts" to the directory of the python executable.
>
> So the proposed change *will* break cx_Freez
On Sat, Mar 24, 2012 at 4:38 AM, Brian Curtin wrote:
> On Fri, Mar 23, 2012 at 18:38, Yury Selivanov wrote:
>> On 2012-03-23, at 7:28 PM, Brian Curtin wrote:
>>> This seems like it should have been a PEP, or maybe should become a PEP.
>>
>> Why? AFAIK Victor just proposes to add two new function
On Sun, Mar 25, 2012 at 1:41 AM, Ben Finney wrote:
> PJ Eby writes:
>> Not every tab in my browser is text for reading; some are apps that
>> need the extra horizontal space.
>
> So, again, why make your browser window *for reading text* that large?
Because he prefers controlling the content vi
collapse
> it and expand it again, the content is shown at your current scroll location).
>
> Have fun!
> Georg
>
> ___
> Python-Dev mailing list
> Python-Dev@python.org
> http://mail.python.org/mailman/listinfo/python-dev
> Unsubscribe:
> http://ma
On Sun, Mar 25, 2012 at 11:04 AM, Stefan Krah wrote:
> Do you mean a fixed search box like this one?
>
> http://coq.inria.fr/documentation
>
> Please don't do this, I find scrolling exceptionally distracting in the
> presence of fixed elements.
Does it bother you when the header is fixed and con
On Sun, Mar 25, 2012 at 2:34 PM, Stefan Krah wrote:
> Stephen J. Turnbull wrote:
>> Does it bother you when the header is fixed and contains
>> the search box? I prefer that arrangement, anyway.
>
> Do you have an example website?
Not with just a header. http://turn
On Tue, Mar 27, 2012 at 1:35 AM, PJ Eby wrote:
> On Sun, Mar 25, 2012 at 2:56 AM, Stephen J. Turnbull
> wrote:
>>
>> But since he's arguing the
>> other end in the directory layout thread (where he says there are many
>> special ways to invoke Python
On Mon, Mar 26, 2012 at 6:42 AM, Terry Reedy wrote:
>> Of course you can always use a user stylesheet to override our choices.
>
> Can anyone tell me the best way to do that with FireFox?
http://kb.mozillazine.org/UserContent.css
explains clearly enough. I can't help you with your particular ve
On Wed, Mar 28, 2012 at 4:45 AM, PJ Eby wrote:
> [ body { width: 65em; } ] won't work - it'll make the entire page
> that width, instead of just text paragraphs.
True (I realized that might be bad in many cases later -- should have
tested first rather than posting something random), but despite
On Thu, Mar 29, 2012 at 1:14 AM, Nick Coghlan wrote:
> That means choosing a name for the version that falls back to time()
> if monotonic() isn't available so it can be safely substituted for
> time.time() without having to worry about platform compatibility
> implications.
What's wrong with "ti
On Fri, Mar 30, 2012 at 7:50 AM, Brian Curtin wrote:
> On Thu, Mar 29, 2012 at 17:45, Benjamin Peterson wrote:
>> 2012/3/29 Brian Curtin :
>>> After talking with Martin and several others during the language
>>> summit and elsewhere around PyCon, PEP 397 should be accepted. I don't
>>> remember w
On Sat, Mar 31, 2012 at 8:46 AM, Guido van Rossum wrote:
> Given the amount of disagreement I sense, I think we'll need to wait
> for more people to chime in.
I currently can't imagine why I *personally* would want anything
better than what we currently call time.time. For that reason, I like
Ca
On Thu, Apr 5, 2012 at 8:05 AM, Oleg Broytman wrote:
> Well, I am partially retreat. "Errors should never pass silently.
> Unless explicitly silenced." get_clock(FLAG, on_error=None) could return
> None.
I still don't see what's erroneous about returning None when asked for
an object that is do
On Thu, Apr 5, 2012 at 10:34 PM, Oleg Broytman wrote:
> Why doesn't open() return None for a non-existing file? or
> socket.gethostbyname() for a non-existing name?
That's not an answer to my question, because those calls have very
important use cases where the user knows the object exists (an
On Fri, Apr 6, 2012 at 12:22 AM, Oleg Broytman wrote:
> On Thu, Apr 05, 2012 at 11:45:06PM +0900, Stephen J. Turnbull wrote:
>> On Thu, Apr 5, 2012 at 10:34 PM, Oleg Broytman wrote:
>> > Why doesn't open() return None for a non-existing file? or
>> > socket.ge
On Fri, Apr 6, 2012 at 3:39 PM, Glyph Lefkowitz wrote:
> There seems to be a persistent desire in this discussion to specify and
> define these flaws out of existence, where this API really should instead be
> embracing the flaws and classifying them.
That seems to be precisely what Cameron is a
1301 - 1400 of 1553 matches
Mail list logo
