Re: [Python-Dev] in
: On 3 April 2018 at 20:34, Ethan Furman wrote: > This behavior was recently brought to my attention [1]: > > --> 1 in 'hello' > Traceback (most recent call last): > File "", line 1, in > TypeError: 'in ' requires string as left operand, not int > > However, in any other collection (set, dict, list, tuple, etc), the answer > would be False. > > Does anyone remember the reason why an exception is raised in the string > instance instead of returning False? The comparison doesn't seem to me to be valid: the 'in' operator for all of those other collections tests whether an element is a member of a collection, whereas for a string it tests whether a string is a substring of another string. In the first case, arbitrary objects can be members, but e.g. [2, 3, 4] in [1, 2, 3, 4, 5] is False. In the second case, no non-string can ever be 'in' a string, but 'bcd' in 'abcde' is True. It's kinda-sorta like addition for numerics versus sequences; they do different things. -[]z. ___ 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] (name := expression) doesn't fit the narrative of PEP 20
: On 25 April 2018 at 21:28, Guido van Rossum wrote: > A very emotional appeal, you don't seem to grasp the usability improvements > this will give. I hear you but at this point appeals to Python's "Zen" don't > help you. I have to admit, in half-following this discussion I've swung between thinking "there's no way this is actually going to happen" and "what, this might actually happen?" Since it now looks like it really *does* have a decent chance, and maybe another -1 has a small chance of tipping the balance: my reaction to the proposal is also emotional. Visceral, in fact, to the extent that I'd aim to read and write less Python if it became commonplace. I don't have arguments. I just have an instinctive "ugh, no". -[]z. ___ 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] [RELEASED] Python 3.5.0b1 is now available
: On Sun, May 24, 2015 at 04:39:00PM -0700, Larry Hastings wrote: > > You can find Python 3.5.0b1 here: > >https://www.python.org/downloads/release/python-350b1/ Source tarballs (both .tgz and .tar.xz) are missing ... -[]z. -- Zero Piraeus: vive ut vivas http://etiol.net/pubkey.asc ___ 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] [RELEASED] Python 3.5.0b1 is now available
: On Sun, May 24, 2015 at 06:03:50PM -0700, Ned Deily wrote: > Zero Piraeus wrote: > > Source tarballs (both .tgz and .tar.xz) are missing ... > > They seem to be there now. Are you still not able to download them? Oops. Both Larry's reply to me and my thankyou to him turn out to have been offlist. Yes, got 'em now. Turns out to have been a permissions error (which the 403 error would have alerted me to, had I been paying attention). So, in public this time: Thanks, Larry (and thanks for all the work on the release) ... -[]z. -- Zero Piraeus: inter caetera http://etiol.net/pubkey.asc ___ 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] Enum Eccentricities
: On Sun, Sep 22, 2013 at 04:52:36PM -0700, Ethan Furman wrote: > So, as anyone who has worked with Enum is probably aware by now, > Enum's are a strange duck -- you might even call them platypuses. Yes :-) > What I'm looking for feedback on is the question is #19011: should an > Enum member be considered a class level attribute? I may be misunderstanding the use case given in the issue, but it seems to me that having to use Color.red.__class__.blue (what is being complained about in the issue), while not exactly pretty, makes a lot more semantic sense than Color.red.blue ... which is just bizarre. Enum members aren't class attributes, even if the way they're defined makes them look as though they are. Allowing this is just asking for more confusion on the part of anyone using them IMHO. -[]z. -- Zero Piraeus: omnia omnibus http://etiol.net/pubkey.asc ___ 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] Enum Eccentricities
On Mon, Sep 23, 2013 at 09:45:46AM -0400, Chris Lambacher wrote:
> [...] The exact use case is in Django templates where a value comes
> from the database. If you want to compare you either have to use
> __class__ which I would say is a code smell, or you have
> to provide the Enum class.
I'm having a hard time seeing why the latter is problematic, I must
admit (certainly no more so than the "Alice in Wonderland" side effects
previously described).
> [...] An example of how this will be used in practice is:
>
> {% if object.state == object.state.completed %}
> some html
> {% endif %}
The names used slightly obscure the weirdness of it, but what you're
really saying there is:
if my_state == my_state.another_state
... which feels more like a code smell to me than
{% if object.state == State.completed %}
some html
{% endif %}
That's quite intelligible, and doesn't require anyone to know that an
Enum member's siblings can, in your proposal, be accessed directly via
dot notation (an unintuitive state of affairs, to me at least).
-[]z.
--
Zero Piraeus: omnia omnibus
http://etiol.net/pubkey.asc
___
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] cpython: Rename contextlib.ignored() to contextlib.ignore().
: On Fri, Oct 11, 2013 at 08:01:07PM +0100, MRAB wrote: > On 11/10/2013 19:41, Glenn Linderman wrote: > >Insistence on using "with" for the anti-pattern, and proper English, > >would require: > > > >with ignorance_of(FileNotFoundError) > > > "Ignorance" means not knowing, but we _do_ know about FileNotFoundError. > What we want is to ignore it. Suggestions: with disregard_for(...): with indifference_to(...): with nonchalance_regarding(...): with blithe_disdain_concerning(...): -[]z. -- Zero Piraeus: dictatum erat http://etiol.net/pubkey.asc ___ 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] cpython: Rename contextlib.ignored() to contextlib.ignore().
: On Tue, Oct 15, 2013 at 10:18:56AM +1000, Nick Coghlan wrote: > I didn't articulate the point very well. The reason I originally > approved the change (and the reason I have kept it despite the > objections raised) is because it allows correct-but-ugly code like: > > try: > os.unlink(fname) > except FileNotFoundError: > pass > > To be rewritten as the significantly more elegant: > > with ignore(FileNotFoundError): > os.unlink(fname) I thought that was already clear, to be honest. As an aside, calling the try/except construct above "ugly" seems a stretch to me - it's a little verbose if you're going to be using it a lot, but presumably in that case you'd just wrap it in a safe_unlink() convenience function if it became annoying. > This benefit when used correctly then needs to be weighed against the > risk of it being used *incorrectly*, especially by people that expect > it to work like VB's "on error resume next" rather than by suppressing > the exception and resuming execution after the with statement. > > The problem of overbroad exception handling isn't a new one, though, > and I don't believe this feature makes that problem *worse*, and, by > making it simpler and cleaner to suppress exceptions from a single > statement, may make it better. For example, this code is wrong: > > try: > os.unlink(fname) > os.unlink(fname2) > except FileNotFoundError: > pass Yes, it's bad code, but it's more intuitively obvious what it does (and therefore that it's badly written) than the equivalent with ignore(FileNotFoundError): os.unlink(fname) os.unlink(fname2) ... as others have pointed out. The above suffers from the same (famously solved by Python) problem as C code with inconsistent braces and indentation: there's a disconnect between what it looks like and what it does. I think one problem is that ignore() doesn't actually do what its name suggests - the flow of execution is changed if an exception occurs, which by definition means the exception isn't being ignored. Maybe it would be better to call it silence()? That's still not perfect IMO, but it's closer to an accurate description of what's going on. -[]z. -- Zero Piraeus: obiter dictum http://etiol.net/pubkey.asc ___ 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] cpython: Rename contextlib.ignored() to contextlib.ignore().
: On Tue, Oct 15, 2013 at 10:05:41PM +1000, Nick Coghlan wrote: > I've come to the conclusion it makes sense to rename it from ignore to > suppress, since that's the term already used for this operation in the > rest of the context management docs: http://bugs.python.org/issue19266 > > Given the number of people vehemently opposed to the old name, I'm > sure there will be plenty of volunteers to create a patch while I do > some more work on PEP 453 :) Patch submitted :-) -[]z. -- Zero Piraeus: dictatum erat http://etiol.net/pubkey.asc ___ 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] cpython: Rename contextlib.ignored() to contextlib.ignore().
:
On Tue, Oct 15, 2013 at 09:45:59AM -0700, Ethan Furman wrote:
> [...] if the CM provides the value before, and the with block accepts
> it, it can then have the exception added to it:
>
> with trap(OSError) as cm:
> os.unlink('missing.txt')
> if cm.exc:
> do_something()
Is there some advantage to this over
try:
os.unlink('missing.txt')
except OSError as exc:
do_something()
I thought the whole point was to replace code that would otherwise
contain 'except: pass' with something slightly more concise. Once you
expose the exception, it becomes just an uglier version of a try/except
block, as far as I can see.
-[]z.
--
Zero Piraeus: pons asinorum
http://etiol.net/pubkey.asc
___
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] Exact date of Python 2 EOL?
: On Thu, 2017-03-23 at 21:08 -0300, Joao S. O. Bueno wrote: > In Python 2, 2/8 is just 0. 27/7 is 3 in Python 2, and between 3.8 and 3.9 in Python 3 (which is probably about where 3.x will be). -[]z. ___ 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] Python startup time
: On 19 July 2017 at 21:19, Steven D'Aprano wrote: > But the premise is wrong too. Those hypothetical people don't turn their > Macs on in sequence, each person turning their computer on only after > the previous person's Mac had finished booting. They effectively boot > them up in parallel but offset, spread out over a 24 hour period, so > about 3472 people booting up at the same time each minute of the day. > Time savings for parallel processes don't add in the way Jobs adds them, > if we treat this as 1440 parallel processes (one per minute of the day) > we save 1440 hours a year. Ah, but the relevant unit here is person-hours, not hours: Jobs is claiming that *each* Mac user loses X% of *their* life to boot times, and then adds all those slices of life together into N lifetimes (which again, are counted in person-years, not years). It's still wrong, though: longer boot times actually increase the proportion of your life spent in meaningful activity (e.g. going to the canteen and talking to someone). -[]z. ___ 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
