Re: [Python-Dev] Where are bugs with the web site reported?

R. David Murray wrote: python.org bugs are *not* reported on bugs.python.org. I don't remember where they are reported...it's on github somewhere I think. The fact that it isn't obvious may be a good candidate for a bug report :) But... which bug tracker should it be reported to? :-) -- Greg

Re: [Python-Dev] PEP 498 f-string: please remove the special case for spaces

Cameron Simpson wrote: To illustrate, there's a consumer rights TV snow here with a segment called "F.U. Tube", where members of the public describe ripoffs and other product failures in video form. While a phonetic play on the name "YouTube", the abbreviation also colloquially means just what

Re: [Python-Dev] PEP-498: Literal String Formatting

Stefan Behnel wrote: Syntax highlighting and in-string expression completion should eventually help, once IDEs support it. Concerning that, this is going to place quite a burden on syntax highlighters. Doing it properly will require the ability to parse arbitrary Python expressions, or at least

Re: [Python-Dev] Update PEP 7 to require curly braces in C

Brett Cannon wrote: For me, I don't see how:: if (x != 10) return NULL; do_some_more(); is any clearer or more readable than:: if (x != 10) { return NULL; } do_some_more(); Maybe not for that piece of code on its own, but the version with braces takes up one more line. Put

Re: [Python-Dev] Update PEP 7 to require curly braces in C

Alexander Walters wrote: When someone trying to make this argument in #python for Python code... the response is newlines are free. Well, I disagree. I very rarely put blank lines in a function in any language, because it makes it hard to scan the code visually and pick out the beginnings of fu

Re: [Python-Dev] Update PEP 7 to require curly braces in C

Alexander Walters wrote: I am not a core developer, but I just kind of feel its hypocritical to oppose always using brackets for the development of *python* If we were being *really* pythonic, we would write all the C code without any braces at all, and feed it through a filter that adds them b

Re: [Python-Dev] PEP 509: Add a private version to dict

Yury Selivanov wrote: What I propose is to add a pointer "ma_extra" (same 64bits), which will be set to NULL for most dict instances (instead of ma_version). "ma_extra" can then point to a struct that has a globally unique dict ID (uint64), and a version tag (unit64). Why not just use a single

Re: [Python-Dev] PEP 509: Add a private version to dict

Andrew Barnert via Python-Dev wrote: imagine someone manages to remove the GIL from CPython by using STM: now most transactions are bumping that global counter, meaning most transactions fail and have to be retried, If this becomes a problem, the tag could be split into two parts of m and n bit

Re: [Python-Dev] Speeding up CPython 5-10%

Sven R. Kunze wrote: Are there some resources on why register machines are considered faster than stack machines? If a register VM is faster, it's probably because each register instruction does the work of about 2-3 stack instructions, meaning less trips around the eval loop, so less unpredict

[Python-Dev] Time for a change of random number generator?

The Mersenne Twister is no longer regarded as quite state-of-the art because it can get into states that produce long sequences that are not very random. There is a variation on MT called WELL that has better properties in this regard. Does anyone think it would be a good idea to replace MT with

Re: [Python-Dev] Wordcode v2

Guido van Rossum wrote: An unfortunate issue however is that many projects seem to make a hobby of hacking bytecode. All those projects would have to be totally rewritten in order to support the new wordcode format Maybe this argues for having an assembly-language-like intermediate form between

Re: [Python-Dev] Very old git mirror under github user "python-git"

Mathieu Dupuy wrote: A python representative (like Guido himself) should contact Github to obtain coordinates of the owner... ...and then order a drone strike on him? -- Greg ___ Python-Dev mailing list Python-Dev@python.org https://mail.python.org/m

Re: [Python-Dev] The next major Python version will be Python 8

Serhiy Storchaka wrote: Does it combine the base of Python 2 with the power of Python 3? No, that would be Python Backwards-Six. -- Greg ___ Python-Dev mailing list Python-Dev@python.org https://mail.python.org/mailman/listinfo/python-dev Unsubscribe

Re: [Python-Dev] Which version is better? Phyton 27 or Phyton 35?

Chris Angelico wrote: In this era of international foods in every supermarket aisle, you cannot simply dismiss the black marks as "funny spots" and wish they'd just go away; you MUST have a fungicide which can adequately handle them. At least there's a standard for the spots now. It used to be

Re: [Python-Dev] When should pathlib stop being provisional?

Nick Coghlan wrote: The most promising option for that is probably "getattr(path, 'path', path)", Is there something seriously wrong with str(path)? -- Greg ___ Python-Dev mailing list Python-Dev@python.org https://mail.python.org/mailman/listinfo/py

Re: [Python-Dev] When should pathlib stop being provisional?

Nick Coghlan wrote: I'd missed the existing precedent in DirEntry.path, so simply taking that and running with it sounds good to me. It's not quite the same thing, though. DirEntry.path takes something that is not a path (a DirEntry instance) and gives you a path representing it, so the name ma

Re: [Python-Dev] Defining a path protocol

Chris Barker - NOAA Federal wrote: But fspath(), if it exists, would call __fspath__ on an arbitrary object, and create a new string -- not a new Path. That may be confusing... Maybe something like fspathstr/__fspathstr__ would be better? -- Greg ___

Re: [Python-Dev] Defining a path protocol

Chris Angelico wrote: -1 for __os_path__, unless it's reasonable to justify it as "most of the standard library uses Path objects, but os.path uses strings, so before you pass a Path to anything in os.path, you call path.ospath() on it, which calls __os_path__()". A less roundabout interpretati

Re: [Python-Dev] Pathlib enhancments - method name only

Brett Cannon wrote: Depends if you use `/` or `\` as your path separator Or whether your pathnames look entirely different, e.g VMS: device:[topdir.subdir.subsubdir]filename.ext;version Pathnames are very much OS-dependent in both syntax *and* semantics. Even the main two in use today (un

Re: [Python-Dev] pathlib (was: Defining a path protocol)

Nick Coghlan wrote: We want to be able to readily use the protocol helper in builtin modules like os and low level Python modules like os.path, which means we want it to be much lower down in the import hierarchy than pathlib. Also, it's more general than that. It works on any object that wants

Re: [Python-Dev] Pathlib enhancments - method name only

Eric Snow wrote: All this matters because it impacts the value returned from __ospath__(). Should it return the string representation of the path for the current OS or some standardized representation? What standardized representation? I'm not aware of such a thing. I'd expect the former. H

Re: [Python-Dev] Pathlib enhancments - method name only

On 9 April 2016 at 23:02, R. David Murray wrote: That is, a 'filename' is the identifier we've assigned to this thing pointed to by an inode in linux, but an os path is a text representation of the path from the root filename to a specified filename. That is, the path *is* the name, so to say

Re: [Python-Dev] Pathlib enhancments - method name only

Nick Coghlan wrote: Similar to my proposal for dealing with DirEntry.path being a bytes-like object, I'd like to suggest raising TypeError in __fspath__ if the request is nonsensical for the currently running system - *nix systems can *manipulate* Windows paths (and vice-versa), but actually tryi

Re: [Python-Dev] Pathlib enhancements - acceptable inputs and outputs for __fspath__ and os.fspath()

Ethan Furman wrote: # after new protocol with bytes/str support def zingar(a_path): a_path = fspath(a_path) if not isinstance(a_path, (bytes,str)): raise TypeError('bytes or str required') ... I think that one would be just def zingar(a_path): a_path =

Re: [Python-Dev] Challenge: Please break this! (a.k.a restricted mode revisited)

Jon Ribbens wrote: So far it looks like blocking "_*" and the frame object attributes appears to be sufficient. Even if your sandbox as it currently exists is secure, it's only an extremely restricted subset. You seem to be assuming that if your technique works so far, then it can be extended t

Re: [Python-Dev] pathlib - current status of discussions

Chris Barker - NOAA Federal wrote: Why in the world do the os.path functions need to work with Path objects? So that applications using path objects can pass them to library code that uses os.path to manipulate them. I'm confused about what a bytes path IS -- is it encoded? It's a sequence

[Python-Dev] Bug in 2to3 concerning import statements?

It seems that 2to3 is a bit simplistic when it comes to translating import statements. I have a module GUI.py2exe containing: import py2exe.mf as modulefinder 2to3 translates this into: from . import py2exe.mf as modulefinder which is a syntax error. It looks like 2to3 is getting confus

Re: [Python-Dev] Bug in 2to3 concerning import statements?

Brett Cannon wrote: There's all sorts of weird stuff going on in that import, like having a dot in the `from` part of the import instead of doing `from .py2exe import mf as modulefinder`. If I did that, it would try to import mf from the py2exe submodule rather than the global one. In hindsi

Re: [Python-Dev] Return type of alternative constructors

Guido van Rossum wrote: We could also consider this a general weakness of the "alternative constructors are class methods" pattern. If instead these alternative constructors were folded into the main constructor (e.g. via special keyword args) it would be altogether clearer what a subclass shou

Re: [Python-Dev] file system path protocol PEP

Paul Moore wrote: On 13 May 2016 at 17:57, Ethan Furman wrote: 1) What is a wallet garden? I assumed he meant "walled garden" Works either way -- you'd want a wall around your wallet garden to stop people stealing your wallets. -- Greg ___ Pytho

Re: [Python-Dev] Adding NewType() to PEP 484

Guido van Rossum wrote: Also -- the most important thing. :-) What to call these things? We're pretty much settled on the semantics and how to create them (A = NewType('A', int)) but what should we call types like A when we're talking about them? "New types" sounds awkward. Fake types? Virtual

Re: [Python-Dev] Adding NewType() to PEP 484

Steven D'Aprano wrote: TypeAlias? Because A is an alias for int? That suggests it's just another name for the same type, but it's not. It's a distinct type as far as the static type checker is concerned. -- Greg ___ Python-Dev mailing list Python-De

Re: [Python-Dev] Python parser performance optimizations

Steven D'Aprano wrote: That can't be right. How can you reduce memory usage by more than one hundred percent? That would mean you have saved more memory than was originally used and are now using a negative amount of memory. It emails an order for more RAM to Amazon, who send out a robot drone

Re: [Python-Dev] Assign(expr* targets, expr value) - why targetS?

anatoly techtonik wrote: where is code that validates that the structure is correct? Is it done on the first level - text file parsing, before ASDL is built? If so, then what is the role of this ADSL exactly that the first step is unable to solve? I think it's done by the code that traverses th

Re: [Python-Dev] [Python-checkins] cpython: Close #17828: better handling of codec errors

Walter Dörwald wrote: Unfortunaty the frame from the decorator shows up in the traceback. Maybe the decorator could remove its own frame from the traceback? -- Greg ___ Python-Dev mailing list Python-Dev@python.org https://mail.python.org/mailman/lis

Re: [Python-Dev] unicode Exception messages in py2.7

Armin Rigo wrote: I figured that even using the traceback.py module and getting "Exception: \u1234\u1235\u5321" is rather useless if you tried to raise an exception with a message in Thai. But at least it tells you that *something* went wrong, and points to the place in the code where it happen

Re: [Python-Dev] (#19562) Asserts in Python stdlib code (datetime.py)

Gregory Salvan wrote: I believe the point of removing assertions is also to avoid throwing unhandled developper errors to end-user I'm not sure I buy that. An assert is saying that something should never happen. If it does happen, either it's going to lead to an exception further down the track

Re: [Python-Dev] Which direction is UnTransform? / Unicode is different

My thought on this for the day, for what it's worth: Anything that doesn't have directions clearly identifiable as "encoding" and "decoding" maybe shouldn't be called a "codec"? -- Greg ___ Python-Dev mailing list Python-Dev@python.org https://mail.pyth

Re: [Python-Dev] PEP 0404 and VS 2010

mar...@v.loewis.de wrote: Package authors would have to create multiple binary releases of the same modules for Windows, and upload them to PyPI. pip would have to learn to download the right one, depending on what build of Python 2.7 is running. Is that much different from package authors havi

Re: [Python-Dev] PEP 0404 and VS 2010

Kristján Valur Jónsson wrote: The "namespace" question from Christian has to do with a "python28.dll" which would be built using VS2010, that this would never clash with a CPython version built the same way. However, it *would* clash with someone else who did the same thing, e.g. Fred Bloggs r

Re: [Python-Dev] PEP 0404 and VS 2010

Concerning the version number, I thought the intention of PEP 404 was simply to say that the PSF would not be releasing anything called Python 2.8, not to forbid anyone *else* from doing so. Or am I wrong about that? If I'm right, there's nothing stopping Christian from releasing Stackless Pytho

Re: [Python-Dev] PEP 0404 and VS 2010

Ethan Furman wrote: [Redirecting to Python Dev] On 11/22/2013 10:25 AM, Richard Tew wrote: > Yet, we're told we should adopt wacky version numbers like 10, or rename our project from Stackless Python. Sometimes we have to do wacky stuff to avoid unnecessary confusion. Maybe imaginary versi

Re: [Python-Dev] PEP 428 - pathlib API questions

Ben Hoyt wrote: However, it seems there was no further discussion about why not "extension" and "extensions"? I have never heard a filename extension being called a "suffix". You can't have read many unix man pages, then! I just searched for "suffix" in the gcc man page, and found this: Fo

Re: [Python-Dev] How long the wrong type of argument should we limit (or not) in the error message (C-api)?

David Hutto wrote: Being that python is, to me, a prototyping language, then every possible outcome should be presented to the end user. So we should produce a quantum superposition of error messages? :-) (Sorry, I've been watching Susskind's lectures on QM and I've got quantum on the brain at

Re: [Python-Dev] Python3 "complexity" (was RFC: PEP 460: Add bytes...)

Kristján Valur Jónsson wrote: all you want is to open that .txt file on the drive and extract some phone numbers and merge in some email addresses. What encoding does the file have? Do I care? Must I care? To some extent, yes. If the encoding happens to be an ascii-compatible one, such as latin

Re: [Python-Dev] Python3 "complexity"

INADA Naoki wrote: latin1 is OK but is it Pythonic? Latin is most certainly a Pythonic subject: http://www.youtube.com/watch?v=IIAdHEwiAy8 -- Greg ___ Python-Dev mailing list Python-Dev@python.org https://mail.python.org/mailman/listinfo/python-dev

Re: [Python-Dev] PEP 460: allowing %d and %f and mojibake

Paul Moore wrote: I could easily argue at this point that this is the type of bug that having %-formatting operations on bytes would encourage - %s means "format a string" (from years of C and Python (text) experience) so I automatically supply a string argument when using %s in a bytes formattin

Re: [Python-Dev] PEP 460: allowing %d and %f and mojibake

Nick Coghlan wrote: On 13 Jan 2014 01:22, "Kristján Valur Jónsson" > wrote: > Well, my suggestion would that we _should_ make it work, by having the %s format specifyer on bytes objects mean: str(arg).encode('ascii', 'strict') > It is not explicit, it is impli

Re: [Python-Dev] PEP 460: allowing %d and %f and mojibake

Paul Moore wrote: On 12 January 2014 18:26, Ethan Furman wrote: I'm arguing from three PoVs: 1) 2 & 3 compatible code base 2) having the bytes type /be/ the boundary type 3) readable code The only one of these that I can see being in any way an argument against def int_to_bytes(n): retu

Re: [Python-Dev] PEP 460: allowing %d and %f and mojibake

Ethan Furman wrote: Your asciistr, which sometimes returns bytes and sometimes returns text, is absolutely *not* what we want. The kind of third-party thing that *might* fill the bill would be a *function*: bytesformat(b"Content-Length: %d", length) that implements all the %-specifiers we'

Re: [Python-Dev] PEP 460: allowing %d and %f and mojibake

Mark Lawrence wrote: I entirely agree. This would also parallel the conversion flags given here http://docs.python.org/3/library/string.html#format-string-syntax, I quote "Three conversion flags are currently supported: '!s' which calls str() on the value, '!r' which calls repr() and '!a' whic

Re: [Python-Dev] PEP 460 reboot

Guido van Rossum wrote: On Sun, Jan 12, 2014 at 5:27 PM, Ethan Furman wrote: On 01/12/2014 04:47 PM, Guido van Rossum wrote: b'%s' % 'x' == b"'x'" (i.e. the three-byte string containing an 'x' enclosed in single quotes) I'm not sure about the quotes. Would anyone ever actually want those

Re: [Python-Dev] PEP 460 reboot

Glenn Linderman wrote: Quotes in the stream are a great debug hint, without blowing up. But do you really want those quotes turning up in a *binary* stream, where they're somewhere between awkward and near-impossible to spot by eyeballing, and may only be discovered when something else -- likel

Re: [Python-Dev] PEP 460 reboot

Nick Coghlan wrote: By allowing format characters that *do* assume ASCII, the entire construct is rendered unsafe - you have to look inside the format string to determine if it is assuming ASCII compatibility or not, thus the entire construct must be deemed as assuming ASCII compatibility at the

Re: [Python-Dev] PEP 460 reboot

Nick Coghlan wrote: so the latter would be less of an attractive nuisance when writing code that needs to handle arbitrary binary formats and can't assume ASCII compatibility. Hang on a moment. What do you mean by code that "handles arbitrary binary formats"? As far as I can see, the propos

Re: [Python-Dev] PEP 460: allowing %d and %f and mojibake

Stephen J. Turnbull wrote: PBP doesn't think it's a great idea to pass around bytes that are implicitly some other type, but didn't mind it (or got used to it) in Python 2, and so they're not looking at that as a problem that Python 3 can solve. They're looking at Python 3 as the problem that pr

Re: [Python-Dev] PEP 460 reboot

Nick Coghlan wrote: Arbitrary binary data and ASCII compatible binary data are *different things* and the only argument in favour of modelling them with a single type is because Python 2 did it that way. I would say that ASCII compatible binary data is a *subset* of arbitrary binary data. As

Re: [Python-Dev] PEP 460: allowing %d and %f and mojibake

Guido van Rossum wrote: I've now looked at asciistr. (Thanks Glenn and Ethan for the link.) Now that I (hopefully) understand it, I'm worried that a text processing algorithm that uses asciistr might under hard-to-predict circumstances (such as when the arguments contain nothing of interest to t

Re: [Python-Dev] PEP 460 reboot

Glenn Linderman wrote: A mechanism could be defined where "format string" would only contain format specifications, and any other text would be considered an error. Someone already did -- it's called struct.pack(). :-) -- Greg ___ Python-Dev mailing

Re: [Python-Dev] PEP 460 reboot

Nick Coghlan wrote: The mini-language parser has to assume in encoding in order to interpret the format string, and that's *all* done assuming an ASCII compatible format string (which must make life interesting if you try to use an ASCII incompatible coding cookie for your source code I don't t

Re: [Python-Dev] PEP 460: allowing %d and %f and mojibake

Guido van Rossum wrote: def spam(a): r = asciistr('(') if a: r += a.strip() r += asciistr(')') return r The general fix would be to add else: r += a[:0] The awkwardness might be reducable if asciistr let you write something like r = asciistr('(', a) meaning "give me

Re: [Python-Dev] PEP 460: allowing %d and %f and mojibake

Guido van Rossum wrote: Actually, Nick explained that asciistr() + asciistr() returns str, That part seems wrong to me, because it means that you can't write polymorphic byte/string functions that are composable. I would be -1 on that, and prefer that asciistr + asciistr --> asciistr. -- Greg

[Python-Dev] The asciistr problem

Guido van Rossum wrote: I understand that '&' here stands for "any arbitrary combination", but what about searches? Given that asciistr's base class is str, won't it still blow up if you try to use it as an argument to e.g. bytes.startswith()? Equality tests also sound problematic; is b'x' == asc

Re: [Python-Dev] PEP 460 reboot

Ethan Furman wrote: On 01/14/2014 10:11 AM, Jim J. Jewett wrote: But in terms of explaining the text model, that separation is important enough that (2) It *may* be worth creating a virtual split in the documentation. I think (2) is a great idea. I don't think it's suc

Re: [Python-Dev] PEP 460 reboot

Guido van Rossum wrote: Quite a few people have spoken out in favor of loud failures rather than silent "wrong" output. But I think that in the specific context of formatting output, there is a long and IMO good tradition of producing (slightly) wrong output in favor of more strict behavior. Cons

Re: [Python-Dev] PEP 460: allowing %d and %f and mojibake

Nick Coghlan wrote: On 15 Jan 2014 08:00, "Greg Ewing" <mailto:greg.ew...@canterbury.ac.nz>> wrote: > > If so, would it help if asciistr were a built-in > type, so that other things could be made aware of > it? That way lies the Python 2 text model,

Re: [Python-Dev] PEP 460: allowing %d and %f and mojibake

Steven D'Aprano wrote: I don't think mixing bytes and strings makes good semantic sense. It's not about mixing bytes and text -- it's about writing polymorphic code that will work on either bytes *or* text. Not both at the same time. If we had quantum computers, this would be easy to solve: a

Re: [Python-Dev] PEP 461 - Adding % and {} formatting to bytes

Neil Schemenauer wrote: Objects that implement __str__ can also implement __bytes__ if they can guarantee that ASCII characters are always returned, I think __ascii_ would be a better name. I'd expect a method called __bytes__ on an int to return some version of its binary value. -- Greg _

Re: [Python-Dev] PEP 461 - Adding % and {} formatting to bytes

Ethan Furman wrote: Well, I'm not sure what "booted into touch" means, It's a rugby term, referring to kicking the ball over the touch line. As a metaphor, it seems to mean making a problem go away. -- Greg ___ Python-Dev mailing list Python-Dev@pyt

Re: [Python-Dev] PEP 461 updates

Glenn Linderman wrote: x = 354 b"%c" % x Is this an intended exception to the overriding principle? I think it's an unavoidable one, unless we want to introduce an "integer in the range 0-255" type. But that would just push the problem into another place, since b"%c" % byte(x) would then

Re: [Python-Dev] PEP 461 - Adding % and {} formatting to bytes

Nick Coghlan wrote: I have a different proposal: let's *just* add mod formatting to bytes, and leave the extensible formatting system as a text only operation. +1 -- Greg ___ Python-Dev mailing list Python-Dev@python.org https://mail.python.org/mai

Re: [Python-Dev] lambda (x, y):

Brett Cannon wrote: On Fri, Jan 24, 2014 at 10:50 AM, Ram Rachum > wrote: lambda (x, y): whatever http://python.org/dev/peps/pep-3113/ Part of the rationale in that PEP is that argument unpacking can always be replaced by an explicitly named argument and an u

Re: [Python-Dev] Python 3.4: What to do about the Derby patches

Larry Hastings wrote: 3) We hold off on merging the rest of the Derby patches until after 3.4.0 final ships, then we merge them into the 3.4 maintenance branch so they go into 3.4.1. But wouldn't that be introducing a new feature into a maintenance release? (I.e. some functions that didn't ha

Re: [Python-Dev] python 3 niggle: None < 1 raises TypeError

Tim Peters wrote: Guido wanted to drop all the "arbitrary but consistent" mixed-type comparison crud for Python 3. Nobody is asking for a return to the arbitrary-but- [in]consistent mess of Python 2, only to bring back *one* special case, i.e. None comparing less than everything else. I think

Re: [Python-Dev] python 3 niggle: None < 1 raises TypeError

Terry Reedy wrote: To make None a true bottom object, the rich comparison methods would have to special-case None as either argument before looking at the __rc__ special methods of either. I don't think it would be necessary to go that far. It would be sufficient to put the special case *after

Re: [Python-Dev] python 3 niggle: None < 1 raises TypeError

Tim Peters wrote: [Greg Ewing] often one wants to sort a collection of objects having keys that can take on null values. Perhaps that's often true of your code, but it's never been true of mine. It's fairly common in accounting circles. I have a collection of invoices, ea

Re: [Python-Dev] python 3 niggle: None < 1 raises TypeError

Georg Brandl wrote: Seeing how you need a key function in any case for this sort to work, it's only the "or mindate" added, which I can't recognize as "ridiculous amount of boilerplate". Well, I don't much like having to construct a key function in the first place for something as common as sor

Re: [Python-Dev] python 3 niggle: None < 1 raises TypeError

M.-A. Lemburg wrote: The alternative would be adding a new singleton to mean mostly the same thing as None, but having the property of comparing less than all other objects and then recommend its use in the DB-API for Python 3 applications... Which I think would be a *really bad* idea, because

Re: [Python-Dev] python 3 niggle: None < 1 raises TypeError

On 20/02/14 08:23, Glenn Linderman wrote: Of course it is not backwards compatible... but once all the "database related None usage" is switched to "Null usage" it should work the same as before, My problem with this is that there is no clear distinction between "database-related None usage" an

Re: [Python-Dev] PEP 463: Exception-catching expressions

Nick Coghlan wrote: On 21 February 2014 13:15, Chris Angelico wrote: Generator expressions require parentheses, unless they would be strictly redundant. Ambiguities with except expressions could be resolved in the same way, forcing nested except-in-except trees to be correctly parenthesized

Re: [Python-Dev] PEP 463: Exception-catching expressions

Antoine Pitrou wrote: lst = [1, 2] value = lst[2] except IndexError: "No value" the gain in concision is counterbalanced by a loss in readability, This version might be more readable: value = lst[2] except "No value" if IndexError since it puts the normal and exceptional values ne

Re: [Python-Dev] Tangent on class level scoping rules (was Re: PEP 463: Exception-catching expressions)

Nick Coghlan wrote: As Chris later noted, you likely *could* still implement expression local name binding for an except expression without a full closure, it would just be rather difficult. I'm still not convinced it would be all *that* difficult. Seems to me it would be semantically equivalen

Re: [Python-Dev] PEP 463: Exception-catching expressions

Eli Bendersky wrote: For instance, it is sometime non-trivial to know which exceptions some function may throw. When you write a try...raise statement, you think hard about covering all the bases. In an expression you're unlikely to, Speak for yourself. I don't think I would put any less thoug

Re: [Python-Dev] PEP 463: Exception-catching expressions

Chris Angelico wrote: it wouldn't be that big a deal to completely reject multiple except clauses and simply require that the (rest of original post truncated) Oh, no! The PSU has gotten wind of this proposal and doesn't like it! -- Greg ___ Python-

Re: [Python-Dev] PEP 463: Exception-catching expressions

Ethan Furman wrote: On 02/21/2014 03:29 PM, Greg Ewing wrote: value = lst[2] except "No value" if IndexError It does read nicely, and is fine for the single, non-nested, case (which is probably the vast majority), but how would it handle nested exceptions? Hmmm, probably not

Re: [Python-Dev] PEP 463: Exception-catching expressions

Steven D'Aprano wrote: result = computation( int(arg) except ValueError: abort("Invalid int") ) Actually, not quite so nice as I first thought, since you're relying on the side-effects of abort() rather than returning a value. Yeah, while I was writing t

Re: [Python-Dev] Tangent on class level scoping rules (was Re: PEP 463: Exception-catching expressions)

Chris Angelico wrote: On Sat, Feb 22, 2014 at 10:57 AM, Greg Ewing wrote: I'm still not convinced it would be all *that* difficult. Seems to me it would be semantically equivalent to renaming the inner variable and adding a finally clause to unbind it. Is there something I'm mis

Re: [Python-Dev] PEP 463: Exception-catching expressions

Steven D'Aprano wrote: Return the value for key if key is in the dictionary, else default. If default is not given, it defaults to None, so that this method never raises a KeyError. I think that's supposed to mean that it won't raise KeyError as a result of the key not being in the

Re: [Python-Dev] Reference cycles in Exception.__traceback__

Antoine Pitrou wrote: We might allow the creation of traceback objects, but without any custom frame objects it is unclear how useful that would be. When I was implementing Pyrex, I would have found it very useful to be able to create Traceback objects without Frames, but only if the Traceback

Re: [Python-Dev] Python 4: don't remove anything, don't break backward compatibility

Chris Angelico wrote: Terrible idea. Would wreak havoc with comparisons. No. Python 3 is all about Unicode, so the right way to proceed is 3.8, 3.9, 3.:, 3.;, 3.<, 3.=, 3.>, 3.?, 3.@, 3.A. And we have all of UCS-4 to play with, so for all practical purposes the 3.x line can live forever! The d

Re: [Python-Dev] Python 4: don't remove anything, don't break backward compatibility

MRAB wrote: What does "irregardless" mean? It's what people say when they misunderestimate the importance of correct prefix usage in English. -- Greg ___ Python-Dev mailing list Python-Dev@python.org https://mail.python.org/mailman/listinfo/python-de

Re: [Python-Dev] Confirming status of new modules in 3.4

Nick Coghlan wrote: On 16 March 2014 01:40, Guido van Rossum wrote: This downside of using subclassing as an API should be well known by now and widely warned against. I've actually pondered the idea of suggesting we explicitly recommend the "procedural facade around an object oriented imple

Re: [Python-Dev] Call for Python Developers for our humanoid Robot NAO

Christian Heimes wrote: Can the NAO bot do The Silly Walk (tm), too? From what I gather, making robots do *non*-silly walks is the hard part. -- Greg ___ Python-Dev mailing list Python-Dev@python.org https://mail.python.org/mailman/listinfo/python-de

Re: [Python-Dev] PEP 461: Adding % formatting to bytes and bytearray -- Final, Take 3

R. David Murray wrote: I've done the 'landmark' thing as well, in the string context; that can be very useful when doing incremental test driven development. (Granted, you could do that with __bytes__; Can't you do it more easily just by wrapping ascii() around the argument? That seems suffici

Re: [Python-Dev] Negative timedelta strings

Alexander Belopolsky wrote: I meant ISO 8601 syntax for "durations" [1]. ISO 8601 doesn't seem to define a representation for negative durations, though, so it wouldn't solve the original problem. -- Greg ___ Python-Dev mailing list Python-Dev@python

Re: [Python-Dev] PEP 465: A dedicated infix operator for matrix multiplication

Alexander Belopolsky wrote: We can start by reviewing the reasons for having separate PyNumber/PySequence/PyMappingMethods structures. I believe that one of the reasons is that many types need to allocate only one of the three. That much is probably true. Numpy arrays, IIRC, allocate all th

Re: [Python-Dev] PEP 465: A dedicated infix operator for matrix multiplication

Victor Stinner wrote: I started to implement the RFC 1924 to have a full support. 3 days later, when my code was working, I saw the date of the RFC... Do you still have the code? It needn't go to waste -- this would make a fine addition to Python's easter egg basket! -- Greg

Re: [Python-Dev] arguments policy: **kwargs.pop()

On 11/04/14 21:50, Chris Barker wrote: On Thu, Apr 10, 2014 at 7:12 PM, Christian Tismer wrote: def __init__(self, **kwargs): first_arg = kwargs.pop('option_1', somedefault) ... nth_arg = kwargs.pop('option_n', somedefault') ... Is: def __init__(self, optio

Re: [Python-Dev] Python "2migr8"

Guido van Rossum wrote: Some quick thoughts: - I'd prefer a name that plays on 2 and 3, not 2 and 8. :-) Python Twee? Or maybe Python Tween, as in "between 2 and 3". -- Greg ___ Python-Dev mailing list Python-Dev@python.org https://mail.python.org/

Re: [Python-Dev] Software integrators vs end users (was Re: Language Summit notes)

Nick Coghlan wrote: there are actually now *two* main ways of consuming Python: Really? We'd better do something about that. We don't want anyone consuming Python -- we want some left over for the rest of us! (I'm making a serious point -- it's annoying when people use the word "consume" as th

<    1   2   3   4   5   6   7   8   9   10   >