Re: [Python-Dev] rst files
On 01/23/2015 03:43 PM, Ethan Furman wrote: Can somebody please explain this? .. index:: single: formatting, string (%) single: interpolation, string (%) single: string; formatting single: string; interpolation single: printf-style formatting single: sprintf-style formatting single: % formatting single: % interpolation Specifically, what does index mean? What does single vs double vs triple mean? Is there a reference somewhere I can read? In restructured text (rst), the .. syntax starts a directive. There are a number of built-in directives, and there is the ability to extend the syntax with domain specific directives. That must be the case here (since there doesn't appear to be a built-in directive named index), so we'll need more information about the source of your rst file before we can answer anything about that particular add on directive. Gary Herron -- Dr. Gary Herron Department of Computer Science DigiPen Institute of Technology (425) 895-4418 ___ Python-Dev mailing list Python-Dev@python.org https://mail.python.org/mailman/listinfo/python-dev Unsubscribe: https://mail.python.org/mailman/options/python-dev/archive%40mail-archive.com
Re: [Python-Dev] PEP 485 review (isclose())
On 02/27/2015 12:07 PM, Chris Barker wrote: Thank you Guido. It'll be nice to see this all come to something. Thanks to all who contributed to the discussion -- despite this being a pretty simple function, I learned a lot and far more fully appreciate the nuance of all of this. I'll edit the text as you suggest, and then work on a patch -- I'm sure I'll have questions for Python-dev when I actually do that, but I'll get started on my own and see how far I get. -Chris There's another typo: The "Large tolerances" section, references a "string test". Perhaps that should be "strong test", but that would seem to contradict the sentence which follows. -- Dr. Gary Herron Department of Computer Science DigiPen Institute of Technology (425) 895-4418 On Fri, Feb 27, 2015 at 11:38 AM, Guido van Rossum <mailto:gu...@python.org>> wrote: I think it's time to accept PEP 485. I've re-read it once more, and it looks like the text is in great shape. (My only recommendation would be to update the Abstract to state that we're specifically adding math.isclose().) A wording question: "This implementation has a flag that lets the user select which relative tolerance test to apply -- this PEP does not suggest that that be retained, but rather than the weak test be selected." -- I think this was meant to say "... rather *that* the weak test be selected", right? (It would be nice if the sample implementation defaulted to the choice in the PEP.) However, those are just minor edits, and I hereby approve the PEP. Thanks Chris and everyone else for the fruitful discussion (and thanks especially to Chris for eventually ending the bikeshedding and writing a PEP that explains each of the choices). Congrats! -- --Guido van Rossum (python.org/~guido <http://python.org/%7Eguido>) -- Christopher Barker, Ph.D. Oceanographer Emergency Response Division NOAA/NOS/OR&R(206) 526-6959 voice 7600 Sand Point Way NE (206) 526-6329 fax Seattle, WA 98115 (206) 526-6317 main reception chris.bar...@noaa.gov <mailto:chris.bar...@noaa.gov> ___ Python-Dev mailing list Python-Dev@python.org https://mail.python.org/mailman/listinfo/python-dev Unsubscribe: https://mail.python.org/mailman/options/python-dev/gherron%40islandtraining.com ___ Python-Dev mailing list Python-Dev@python.org https://mail.python.org/mailman/listinfo/python-dev Unsubscribe: https://mail.python.org/mailman/options/python-dev/archive%40mail-archive.com
[Python-Dev] Re: For-If syntax
On 5/1/20 9:19 AM, silverback...@gmail.com wrote: I hope this isn't too noobish, nothing on the list comes up in Google, but I'm curious why the construct for x in y if x.is_some_thing: # do a thing But this is probably clearer (and has the same syntax): for x in y: if x.is_some_thing: # do a thing Cramming two separate thoughts onto a single line is probably *not* clearer. isn't legal. That seems a very Pythonic symmetry with lambdas. The equivalent syntax required right now is, for x in [x for x in y if x.is_some_thing]: # do a thing Of course there's more flexibility in the full syntax, but is there any interest in the simpler, more performant one-line syntax? Em ___ Python-Dev mailing list -- python-dev@python.org To unsubscribe send an email to python-dev-le...@python.org https://mail.python.org/mailman3/lists/python-dev.python.org/ Message archived at https://mail.python.org/archives/list/python-dev@python.org/message/VHFUQFEF3TCI6LHLBAUEKMFM2A6V3CQO/ Code of Conduct: http://python.org/psf/codeofconduct/ -- Dr. Gary Herron Professor of Computer Science DigiPen Institute of Technology (425) 895-4418 ___ Python-Dev mailing list -- python-dev@python.org To unsubscribe send an email to python-dev-le...@python.org https://mail.python.org/mailman3/lists/python-dev.python.org/ Message archived at https://mail.python.org/archives/list/python-dev@python.org/message/T3VQGGAHYR4AOKMVPL5NDTAV2GB6BIAH/ Code of Conduct: http://python.org/psf/codeofconduct/
Re: [Python-Dev] Does anyone care enough about asyncore and asynchat to help adapt their APIs for Py3k?
Guido van Rossum wrote: > The asyncore and asynchat modules are in a difficult position when it > comes to Python 3000. None of the core developers use it or > particularly care about it (AFAIK), and the API has problems because > it wasn't written to deal with bytes vs. unicode. E.g. in > http://bugs.python.org/issue1067, Thomas suggests that these modules > need to be rewritten to use bytes internally and have separate APIs to > handle (unicode) text as desired, similar to the way file I/O was > redesigned. Another alternative would be to make these modules deal > strictly in bytes, but that would probably vastly reduce their > usefulness (though I don't know -- as I said, I don't use them). > > I use asyncore/asynchat in one (proprietary) project of mine. However, since the only thing I use them for is bytes, your suggested alternative (of bytes instead of strings) is fine with me, and seems the most natural choice. (In fact what I'm currently passing around is strings produced by cPickle, but I'm assuming that the Python3 version of cPickle will create/consume bytes. True?) Gary Herron ___ 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
Re: [Python-Dev] Slice as a copy... by design?
Facundo Batista wrote: Hi! A thread in PyAr raised the question that, considering that strings are immutable, why a slice of a string is a copy and not a reference to a part of that string. I couldn't answer why, so I'm asking here...Is it because the reference counting will be complicated? Is it because it'd be inefficient in other way? It's something else? Or is something that could be done... but is not done yet? Thank you very much! In fact, a slice is *not* always a copy! In at least some (simple) cases, a slice references the original string: >>> s = 'abc' >>> t = s[:] >>> s is t True >>> id(s) 3081872000L >>> id(t) 3081872000L Gary Herron ___ 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
Re: [Python-Dev] the explicit self
Kilian Klimek wrote: Hello, i know this has been discusses very much, i'm sorry, but i can't help it. In a nutshell, the proposal is as follows: 1. Self remains explicit (like it is now). 2. if a class is a subclass of a special class, e.g. named 'selfless', the self parameter is not required and a special variable, named 'this' is provided. For example: class Foo (selfless): def __init__ (x, y): this.x = x ... A patch for 3.0b3 implementing this can be found at http://www-lehre.inf.uos.de/~kklimek/misc/python_slp_8.diff <http://www-lehre.inf.uos.de/%7Ekklimek/misc/python_slp_8.diff> Why not just do this? class Foo: def __init__ (this, x, y): this.x = x It's fewer characters, it gets rid of the "self" you seem to dread, and it requires no patches or changes of any kind to Python. And most importantly, has no need to introduce any "magic" into the language. Gary Herron regards, Kilian Klimek ___ 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/gherron%40islandtraining.com ___ 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
Re: [Python-Dev] Adding a conditional expression in Py3.0
Michael Hudson wrote: >Guido van Rossum <[EMAIL PROTECTED]> writes: > > > >>>Given the later addition of generator expressions with mandatory >>>parentheses , the mandatory-parentheses version of a conditional expression >>>looks less strange to me than it did then ;-). So I could happily use it >>>even though I may still lean toward the other option 2 version (then-else) >>>due to its not needing ':'s or a third elseif term for chaining. >>> >>> >>I think I'd prefer (if then else ) i.e. no >>colons. >> >> > >My problem with this syntax is that it can be hard to read: > >return if self.arg is None then default else self.arg > >looks worryingly like > >return NAME NAME.NAME NAME NAME NAME NAME NAME NAME.NAME > >to me. > > But that's exactly what any language looks like if you get abstract enough: WORD WORD WORD WORD WORD WORD WORD And in fact, one read and understands your return statement just like an English sentence -- word by word from beginning to end. This seems an argument FOR the syntax not against.Moreover, if one uses the proposed parenthesized syntax, even the slightly odd word order of "return if" is mitigated. return (if self.arg is None then default else self.arg) > > >>None of the other expression forms (list comprehensions and >>generator expressions) involving statement keywords use colons. >> >> > >This is also true. > > > >>>*If* you want general community input, I would suggest a runoff ballot with >>>those four choices (and a summary of pros and cons of each), or fewer if >>>you see any as unacceptible. >>> >>> >>If there's one thing I've learned from the PEP 308 vote, it is that >>votes for language don't work. I prefer some discussion on Python-dev >>after which I pick one. >> >> > >Well, this is my input (and now I'm going to try and stay out of it). > >Cheers, >mwh > > > ___ 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
Re: [Python-Dev] Freezing the CVS on Oct 26 for SVN switchover
Guido van Rossum wrote: >Help! > >What's the magic to get $Revision$ and $Date$ to be expanded upon >checkin? Comparing pep-0352.txt and pep-0343.txt, I noticed that the >latter has the svn revision and date in the headers, while the former >still has Brett's original revision 1.5 and a date somewhere in June. >I tried to fix this by rewriting the fields as $Revision$ and $Date$ >but that doesn't seem to make a difference. > >Googling for this is a bit tricky because Google collapses $Revision >and Revision, which makes any query for svn and $Revision rather >non-specific. :-( It's also not yet in our Wiki. > > It's an svn property associated with the file. The property name is svn:keywords, and the value is a space separated list of keywords you'd like to have substituted. Like this: svn propset svn:keywords "Date Revision" ...file list... The list of keywords it will handle is LastChangedDate (or Date) LastChangedRevision (or Revision or Rev) LastChangedBy (or Author) HeadURL (or URL) Id Gary Herron ___ 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
Re: [Python-Dev] Let's just *keep* lambda
Guido van Rossum wrote: >After so many attempts to come up with an alternative for lambda, >perhaps we should admit defeat. I've not had the time to follow the >most recent rounds, but I propose that we keep lambda, so as to stop >wasting everybody's talent and time on an impossible quest. > >-- >--Guido van Rossum (home page: http://www.python.org/~guido/) >___ >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/gherron%40islandtraining.com > > Hear hear! +1 Gary Herron ___ 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
