Federico Salerno wrote:
> On 11/07/2020 19:29, Jim J. Jewett wrote:
> > To me, "else:" has a slightly different meaning than "case _:" ...
> Could you construct two examples to prove behaviour would be different
> between the two?
The behavior would be identi
I don't think anyone has asked for more indentation in that sense; it has only
even come up in a suggestion of less. (2-space indents for case instead of 4)
People do disagree about whether or not case statements (and possibly an else
statement) should be indented more than 0 spaces compared t
Glenn Linderman wrote:
> On 7/10/2020 3:15 AM, Gustavo Carneiro wrote:
...
> > Therefore, I posit that the style of try...except indentation only
> > works where the number of cases is small.
> > But for the case of pattern matching, I expect the number of cases to
> > be matched to be a lot high
To me, "else:" has a slightly different meaning than "case _:"
case _: essentially a default, ensuring that the match logic is
complete.
else: OK, the subject of this match failed, here is our fallback logic.
Whether this distinction is important enough to express in code is anoth
Unless I'm missing something, part of M.-A. Lemburg's objection is:
1. The wchar_t type is itself an important interoperability story in C. (I'm
not sure if this includes the ability, at compile time, to define wchar_t as
either of two widths.)
2. The ability to work directly with wchar_t wi
Specifying British English (as opposed to just British spelling) would probably
tempt people to use more Brit-only idioms, in the same way that Monty Python
tempts people to make Flying Circus references.
I don't love the idea of talking more about how many zeroes in a billion, or
whether "tabl
The biggest problem with this is figuring out when to switch. If you switch
within a single example, you will confuse many readers. If you have a series
of related examples, people will disagree about when it is reasonable to
substitute a new person.
Using specific personal names (Alice and
If the writing is less formal (and I think most comments and even most
documentation is somewhat informal), you can sometimes just address the reader
directly, as "you".
For the most formal writing most people will ever encounter, one can use "one"
as the singular pronoun of indeterminate gende
Nick Coghlan wrote:
> On Thu, 2 Jul 2020 at 00:50, Guido van Rossum gu...@python.org wrote:
> > As to allowing object destructuring syntax like
> > Point(x, y) = p
> > that definitely has merit, but it is a complex subject that should be a
> > separate
> > PEP.
> This is the main point I'm
Guido van Rossum wrote:
> On Wed, Jul 1, 2020 at 5:50 PM Nick Coghlan ncogh...@gmail.com wrote:
> > The key thing I'm hoping for in PEP 622 itself is
> > that "Syntactic compatibility with a possible future
> > enhancement to assignment statements" be considered
> > as a constraint on the syntax fo
I actually like that it looks like instantiation; it seems to be saying "Do we
have the sort of object we would get from this instantiation?"
Unfortunately, this does aggravate the confusion over whether a variable is
being used as a filter, vs binding to something from the matched object.
___
There are the usual concurrency problems of "read a value, change it, store it
back without checking whether it already changed". The only thing special
about lifecycle happens at refcount 0, which should not happen when more than
one interpreter has a reference.
Similarly, C code can mess thi
Even without platform differences, limits on the value of parameters really
ought to be in the docstring, which is available to inspect. If you're asking
for a more specific convention that could actually be used, that still probably
still needs to be written.
__
In fairness, if the process is really exiting, the OS should clear that out.
Even if it is embedded, the embedding process could just release (or zero out)
the entire memory allocation. I personally like plugging those leaks, but it
does feel like putting purity over practicality.
I don't think that sharing data only by copying is the final plan. Proxied
objects seem like a fairly obvious extension.
I am also a bit suspicious of that great timing; perhaps latency is also
important for startup?
___
Python-Dev mailing list -- pyt
David Mertz wrote:
> Fwiw, I don't think it changes my order, but 'strict' is a better word than
> 'equal' in all those places. I'd subtract 0.1 from each of those votes if
> they used "equal".
I would say that 'equal' is worse than 'strict'. but 'strict' is also wrong.
Zipping to a potentiall
Even then, disconnect seems like the primary use case, with a
channel.kill_for_all being a specialized subclass. One argument for leaving it
to a subclass is that it isn't clear what other interpreters should do when
that happens. Shut down? Start getting exceptions if they happen to use it
Ronald Oussoren wrote:
> > On 28 Apr 2020, at 20:38, Jim J. Jewett jimjjew...@gmail.com wrote:
> > Why do sub-interpreters require (separate and) heap-allocated types?
> > It seems types that are statically allocated are a pretty good use for
> > immortal
> > objec
Why do sub-interpreters require (separate and) heap-allocated types?
It seems types that are statically allocated are a pretty good use for immortal
objects, where you never change the refcount ... and then I don't see why you
need more than one copy.
__
Victor Stinner wrote:
> I started to modify Python internals to pass explicitly the Python
> thread state ("tstate") to internal C a functions:
Is work this summarized somewhere like a PEP?
> https://vstinner.github.io/cpython-pass-tstate.html
describes the motivation, but not the details on why
David Mertz wrote:
> On Wed, Dec 11, 2019, 6:40 AM Mark Shannon m...@hotpy.org
> wrote:
> > I NEVER care about memory at all... except inasmuch as it effects speed.
In my admittedly idiosyncratic experience, memory is usually by far my most
constrained resource. I do care about it, even if pyth
There is value in saying "These are things that might be limited by the
implementation."
There is great value in documenting the limits that CPython in particular
currently chooses to enforce. Users may want to see the numbers, and other
implementations may wish to match or exceed these minimu
I wouldn't worry too much about the the Singletons in this issue; they could be
solved in any of several ways, all of which would be improvements conceptually
-- if performance and backwards compatibility were resolved.
In theory, the incr/decr pair should be delegated to the memory store, with
On Wed, Sep 11, 2019 at 5:36 AM Steve Dower wrote:
> But you mention "only do ... stuff if ... there" - what stuff are you
> referring to? The installer should do *less* if it's partially installed
> already, not more.
My understanding was that
(1) You believe the py.exe launcher should be instal
Is it possible for the installer to check whether or not there is a
pre-existing system-wide launcher, and only do the complicated stuff
if it is actually there?
-jJ
___
Python-Dev mailing list -- python-dev@python.org
To unsubscribe send an email to pyt
FWIW, the web archive
https://mail.python.org/archives/list/python-dev@python.org/thread/ZX2JLOZDOXWVBQLKE4UCVTU5JABPQSLB/
does not seem to display the problems ... apparently the individual messages
are not included in view source, and are cleaned up for chrome's inspect. I'm
not sure whether
I think part of the disconnect is that this enhancement could very
easily be abused, and it seems likely that it will be, because the
problems aren't visible while writing the code -- only when reading it
later.
I therefore suggest making it very clear in the PEP -- and probably in
PEP 8 -- how t
On Mon, Feb 19, 2018 at 5:06 PM, Chris Barker - NOAA Federal <
chris.barker at noaa.gov> wrote:
> If I have this right, on the discussion about frozen and hash, a use
> case was brought up for taking a few steps to create an instance (and
> thus wanting it not frozen) and then wanting it hashable.
I understand auto-generating the __hash__ (and __eq__) for a frozen
container; that is just convenient.
But why is there any desire to autogenerate a __hash__ for something
that isn't frozen? Like a list or dict, the normal case would be for
it not to have a hash at all, and the author *should* w
(1) I found the following (particularly "bases classes") very confusing:
"""
If an object that is not a class object appears in the bases of a class
definition, then ``__mro_entries__`` is searched on it. If found,
it is called with the original tuple of bases as an argument. The result
of the c
Does setting an ImplicitScopeVar to None set the value to None, or just
remove it?
If it removes it, does that effectively unmask a previously masked value?
If it really sets to None, then is there a way to explicitly unmask
previously masked values?
Perhaps the initial constructor should requir
I think there is general consensus that this should go in a module other
than sys. (At least a submodule.)
The specific names are still To Be Determined, but I suspect seeing the
functions and objects as part of a named module will affect what works.
So I am requesting that the next iteration jus
On Aug 24, 2017 11:02 AM, "Yury Selivanov" wrote:
On Thu, Aug 24, 2017 at 10:05 AM, Jim J. Jewett
wrote:
> On Thu, Aug 24, 2017 at 1:12 AM, Yury Selivanov > On Thu, Aug 24, 2017
> at 12:32 AM, Jim J. Jewett wrote:
If you look at this small example:
foo = new_context_k
Should PEP 550 discuss other implementations? E.g., the object space used
in pypy?
-jJ
___
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
On Thu, Aug 24, 2017 at 1:12 AM, Yury Selivanov > On Thu, Aug 24, 2017
at 12:32 AM, Jim J. Jewett wrote:
> The key requirement for using immutable datastructures is to make
> "get_execution_context" operation fast.
Do you really need the whole execution context, or do you ju
In https://mail.python.org/pipermail/python-dev/2017-August/148869.html
Nick Coghlan wrote:
> * what we want to capture at generator creation time is
> the context where writes will happen, and we also
> want that to be the innermost context used for lookups
So when creating a generator, we w
Building on Brett's suggestion:
FrameContext: used in/writable by one frame
ContextStack: a FrameContext and its various fallbacks
-jJ
___
Python-Dev mailing list
Python-Dev@python.org
https://mail.python.org/mailman/listinfo/python-dev
Unsubscr
I agree that startup time is a problem, but I wonder if some of the pain
could be mitigated by using a persistent process.
For example, in
https://mail.python.org/pipermail/python-dev/2017-July/148664.html Ben Hoyt
mentions that the Google Cloud SDK (CLI) team has found it "especially
problematic
On Mon, Oct 10, 2016, at 14:04, MRAB wrote:
> Instead of locking the object, could we keep the GIL, but have it
> normally released?
> A thread could then still call a function such as PyWeakref_GetObject()
> that returns a borrowed reference, but only if it's holding the GIL. It
> would be able
On Sat, Apr 16, 2016 at 5:01 PM, Victor Stinner
wrote:
> * I mentionned that version++ must be atomic, and that in the case of
> CPython, it's done by the GIL
Better; if those methods *already* hold the GIL, it is worth saying
"already", to indicate that the change is not expensive.
> * I remove
On Fri, Apr 15, 2016 at 7:31 PM, Victor Stinner
wrote:
> .2016-04-15 23:45 GMT+02:00 Jim J. Jewett :
...
>> I just worry that you may end up closing off even better optimizations
>> later, if you make too many promises about exactly how you will do
>> which ones.
>> T
On Fri, Apr 15, 2016 at 4:41 PM, Victor Stinner
wrote:
> 2016-04-15 19:54 GMT+02:00 Jim J. Jewett :
>> (2) Why *promise* not to update the version_tag when replacing a
>> value with itself?
> It's an useful property. For example, let's say that you have a guard
On Thu Apr 14 11:19:42 EDT 2016, Victor Stinner posted the latest
draft of PEP 509; dict version_tag
(1) Meta Question: If this is really only for CPython, then is
"Standards Track" the right classification?
(2) Why *promise* not to update the version_tag when replacing a
value with itself?
(1) I think the "built-in" should instead be a module-level function
in the pathlib. If you aren't already expecting pathlib paths, then
you're just expecting strings to work anyhow, and a builtin isn't
likely to be helpful.
(2) I prefer that the function be explicit about the fact that it is
d
On Sun Mar 20 16:26:03 EDT 2016, Nikolaus Rath wrote:
> Which I believe makes it completely pointless to cite Python at all. As
> far as I can see, nowadays citations are given for two reasons:
> 1. To give the reader a starting point to get more information on a
>topic.
I don't often see
> On Jan 17, 2016, at 11:10, Brett Cannon wrote:
>> While doing a review of http://bugs.python.org/review/26129/
>> ... update PEP 7 to remove the optionality of curly braces
On Mon Jan 18 03:39:42 EST 2016, Andrew Barnert pointed out:
> There are two ways you could do that.
[The one most p
(1) Please make it clear within the abstract what counts as a change.
(1a) E.g., a second paragraph such as "Adding or removing a key, or
replacing a value, counts as a change. Modifying an object in place,
or replacing it with itself may not be picked up."
(1b) Is there a way to force a vers
PEP 498 is only the latest PEP where part of the concern is fear that
it may encourage certain types of bad code.
Would it be reasonable to ask PEPs to start including a section on any
recommended changes to PEP8? (e.g., "If an embedded expression
doesn't fit on a single line, factor it out to a
On Fri Jun 26 16:51:13 CEST 2015, Paul Sokolovsky wrote:
> So, currently in Python you know if you do:
>socket.write(buf)
> Then you know it will finish without interruptions for entire buffer.
How do you know that?
Are you assuming that socket.write is a builtin, rather than a
python me
On Thu Jun 18 20:33:13 CEST 2015, Larry Hastings asked:
> On 06/18/2015 11:27 AM, Terry Reedy wrote:
>> Unicode 8.0 was just released. Can we have unicodedata updated to
>> match in 3.5?
> What does this entail? Data changes, code changes, both?
Note that the unicode 7 changes also need to
On Sun May 24 12:06:40 CEST 2015, Nick Coghlan wrote:
> On 24 May 2015 at 19:44, Mark Shannon wrote:
>> On 24/05/15 10:35, Nick Coghlan wrote:
>>> If we leave __definition_order__ out for the time being then, for the
>>> vast majority of code, the fact that the ephemeral namespace used to
>>> ev
At Thu May 21 22:27:50 CEST 2015, Guido wrote:
> I want to encourage users to think about annotations as types,
> and for most users the distinction between type and class is
> too subtle,
So what is the distinction that you are trying to make?
That a type refers to a variable (name), and a cl
Mark Shannon wrote:
> PY2, etc. really need to go.
> Assuming that this code type checks OK:
>
> if typing.PY2:
> type_safe_under_py2_only()
> else:
> type_safe_under_py3_only()
>
> Is the checker supposed to pass this:
>
> if sys.hexversion < 0x0300:
> type_safe_under_py2_
Tue May 5 21:48:36 CEST 2015, Yury Selivanov wrote:
> As for terminology, I view this discussion differently. It's
> not about the technical details (Python has asymmetric
> coroutines, that's it), but rather on how to disambiguate
> coroutines implemented with generators and yield-from, from
>
On Tue May 5 21:44:26 CEST 2015,Brett Cannon wrote:
> It's not as
> complicated as it seems when you realize there is an event loop driving
> everything (which people have been leaving out of the conversation since it
> doesn't tie into the syntax directly).
Another reason people don't realize i
On Tue May 5 18:29:44 CEST 2015, Yury Selivanov posted an updated PEP492.
Where are the following over-simplifications wrong?
(1) The PEP is intended for use (almost exclusively) with
asychronous IO and a scheduler such as the asynchio event loop.
(2) The new syntax is intended to make it eas
On Fri May 1 23:58:26 CEST 2015, Yury Selivanov wrote:
>>> Yes, you can't use 'yield from' in __exit__/__enter__
>>> in current Python.
>> What do you mean by "can't use"?
> It probably executed without errors, but it didn't run the
> generators.
True. But it did return the one created by __
On Sun May 3 08:32:02 CEST 2015, Stefan Behnel wrote:
> Ok, fair enough. So, how would you use this new protocol manually then?
> Say, I already know that I won't need to await the next item that the
> iterator will return. For normal iterators, I could just call next() on it
> and continue the f
On Thu Apr 30 21:27:09 CEST 2015, Yury Selivanov replied:
On 2015-04-30 2:41 PM, Jim J. Jewett wrote:
>> Bad phrasing on my part. Is there anything that prevents an
>> asynchronous call (or waiting for one) without the "async with"?
>> If so, I'm missing so
On Fri, May 1, 2015 at 4:10 PM, Guido van Rossum wrote:
> On Fri, May 1, 2015 at 12:48 PM, Jim J. Jewett wrote:
>>
>> If there are more tasks than executors, yield is a way to release your
>> current executor and go to the back of the line. I'm pretty sure I
>&
On Fri, May 1, 2015 at 2:59 PM, Guido van Rossum wrote:
> On Fri, May 1, 2015 at 11:26 AM, Jim J. Jewett wrote:
>>
>> On Thu, Apr 30, 2015 at 3:32 PM, Guido van Rossum
>> wrote:
>>
>> (Guido:)> Actually that's not even wrong. When using generators as
On Thu, Apr 30, 2015 at 3:32 PM, Guido van Rossum wrote:
(me:)
>> A badly worded attempt to say
>> Normal generator: yield (as opposed to return) means
>> that the function isn't done, and there may be more
>> things to return later.
>> but an asynchronous (PEP492) coroutine is primarily saying
On Wed Apr 29 20:06:23 CEST 2015,Yury Selivanov replied:
>> As best I can guess, the difference seems to be that a "normal"
>> generator is using yield primarily to say:
>> "I'm not done; I have more values when you want them",
>> but an asynchronous (PEP492) coroutine is primarily saying:
On Wed, Apr 29, 2015 at 2:26 PM, Paul Moore wrote:
> On 29 April 2015 at 18:43, Jim J. Jewett wrote:
>> So? PEP 492 never says what coroutines *are* in a way that explains
>> why it matters that they are different from generators.
...
> Looking at the Wikipedia article on
On Tue Apr 28 23:49:56 CEST 2015, Guido van Rossum quoted PEP 492:
> Rationale and Goals
> ===
>
> Current Python supports implementing coroutines via generators (PEP
> 342), further enhanced by the ``yield from`` syntax introduced in PEP
> 380. This approach has a number of short
On 16 March 2015 Petr Viktorin wrote:
> If PyModuleCreate is not defined, PyModuleExec is expected to operate
> on any Python object for which attributes can be added by PyObject_GetAttr*
> and retrieved by PyObject_SetAttr*.
I assume it is the other way around (add with Set and retrieve with Ge
On 10 March 2015 at slightly after midnight. Paul Moore wrote:
> Personally I doubt it would make much difference. If the docs say
> "pygmentize" I'm unlikely to dig around to find that the incantation
> "python -m pygments.somemodule:main" does the same thing using 3 times
> as many characters
On Wed, Feb 25, 2015 at 2:33 PM, Paul Moore wrote:
> On 25 February 2015 at 17:06, Paul Moore wrote:
> I've included the resulting API
> documentation below. It looks pretty good to me.
Me too. I have a few nits anyhow.
> .. function:: create_archive(directory, target=None, interpreter=None,
On 24 February 2015 at 18:58, Guido van Rossum wrote:
> The naming of the functions feels inconsistent -- maybe pack(directory,
> target) -> create_archive(directory, archive), and set_interpreter() ->
> copy_archive(archive, new_archive)?
Paul Moore wrote:
> One possible source of confusion w
On Wed, Feb 18, 2015 at 4:16 PM, Paul Moore wrote:
> On 18 February 2015 at 20:48, Jim J. Jewett wrote:
>> Barry Warsaw wrote:
>>>> I don't know exactly what the procedure would be to claim .pyz for *nix,
>>>> e.g. updating /etc/mime.types,
...
&g
Barry Warsaw wrote:
>> I don't know exactly what the procedure would be to claim .pyz for *nix,
>> e.g. updating /etc/mime.types, but I think the PEP should at least mention
>> this. I think we want to get as official support for .pyz files on *nix as
>> possible.
Paul Moore wrote:
> I'll add a
On Thu, Dec 18, 2014, at 14:13, Maciej Fijalkowski wrote:
> ... http://bugs.python.org/issue23085 ...
> is there any reason any more for libffi being included in CPython?
Paul Moore wrote:
> Probably the easiest way of moving this forward would be for someone
> to identify the CPython-specific
On Thu, Dec 18, 2014, at 14:13, Maciej Fijalkowski wrote:
> ... http://bugs.python.org/issue23085 ...
> is there any reason any more for libffi being included in CPython?
[And why a fork, instead of just treating it as an external dependency]
Benjamin Peterson responded:
> It has some sort of
Brett Cannon wrote:
> 4. Contributor creates account on bugs.python.org and signs the
> [contributor agreement](https://www.python.org/psf/contrib/contrib-form/)
Is there an expiration on such forms? If there doesn't need to be
(and one form is good for multiple tickets), is there an objectio
M. Cepl asked:
> What I really don't understand is why this discussion is hg v.
> GitHub, when it should be hg v. git. Particular hosting is
> a secondary issue
I think even the proponents concede that git isn't better enough
to justify a switch in repositories.
They do claim that GitHub (
I have a strong suspicion that I'm missing something; I have been
persuaded both directions too often to believe I have a grip on the
real issue.
So I'm putting out some assumptions; please tell me if I'm wrong, and
maybe make them more explicit in the PEP.
(1) The change will only affect situat
On Sat Sep 13 00:16:30 CEST 2014, Jeff Allen wrote:
> 1. Java does not really have a Unicode type, therefore not one that
> validates. It has a String type that is a sequence of UTF-16 code units.
> There are some String methods and Character methods that deal with code
> points represented
On September 11, 2014, Jeff Allen wrote:
> ... the area of code point
> space used for the smuggling of bytes under PEP-383 is not a
> "Unicode Private Use Area", but a portion of the trailing surrogate
> range. This is a code violation, which I imagine is why
> "surrogateescape" is an error
On Tue, Sep 9, 2014 at 12:11 PM, Christian Heimes wrote:
> On 09.09.2014 05:03, Nick Coghlan wrote:
>>
>> On 9 Sep 2014 10:48, "Jim J. Jewett" > <mailto:jimjjew...@gmail.com>> wrote:
>> From Guido's and your feedback, I think we may need two things
On Mon, Sep 8, 2014 at 3:44 PM, Cory Benfield wrote:
> On 8 September 2014 18:23, Jim J. Jewett wrote:
>> Summary: There needs to be a simple way to opt out at install time.
>> It would be far better to offer more fine-grained control, but leaving
>> that better solu
Summary: There needs to be a simple way to opt out at install time.
It would be far better to offer more fine-grained control, but leaving
that better solution to downstream is acceptable.
On 3 September 2014 01:19, Antoine Pitrou wrote:
> RFC 2818 (HTTP over TLS) has the following language
Sat Aug 2 12:11:54 CEST 2014, Julian Taylor wrote (in
https://mail.python.org/pipermail/python-dev/2014-August/135623.html ) wrote:
> Andrea Griffini wrote:
>>However sum([[1,2,3],[4],[],[5,6]], []) concatenates the lists.
> hm could this be a pure python case that would profit from
On 6/24/2014 4:22 AM, Serhiy Storchaka wrote:
> I submitted a number of patches which fixes currently broken
> Unicode-disabled build of Python 2.7 (built with --disable-unicode
> configure option). I suppose this was broken in 2.7 when C
> implementation of the io module was introduced.
It has
Steven D'Aprano wrote:
> (1) I asked if it would be okay for MicroPython to *optionally* use
> nominally Unicode strings limited to ASCII. Pretty much the only
> response to this as been Guido saying "That would be a pretty lousy
> option", and since nobody has really defended the suggestion,
On Mon, Apr 28, 2014 at 12:56 PM, Charles-François Natali
wrote:
> Why would the user care if multiprocessing is used behind the scene?
Err ... that was another set of questions that I forgot to ask.
(A) Why bother raising an error if multiprocessing is unavailable?
After all, there is a perfec
(1) Should fixes to a docstring go in with a patch, even if they
aren't related to the changing functionality?
Bytestring compilation has several orthogonal parameters. Most -- but
not all -- are documented in the docstring. (Specifically, there is
no explanation of the rx parameter which acts
(1) I believe the recent consensus was that the number of comparisons
made in a dict lookup is an implementation detail. (Please correct me
if I am wrong.)
(2) Is "the item will be hashed at least once" a language guarantee?
For small mappings, it might well be more efficient to just store the
On Mon Mar 10 18:56:17 CET 2014 (and earlier quotes), Maciej Fijalkowski wrote:
Maciej:>> You should not rely on __del__s being called timely one way or
Maciej:>> another. Why would you require this for the program to work
Maciej:>> correctly in the particular example of __traceback__?
To the e
On Fri Mar 7 20:54:31 CET 2014, Chris Angelico wrote:
> On Sat, Mar 8, 2014 at 5:58 AM, Jim J. Jewett wrote:
>> (Thu Mar 6 23:26:47 CET 2014) Chris Angelico responded:
>>> ...[as-capturing is] deferred until there's a non-closure means of
>>> creating a sub-sco
n inside a longer line.
(3a) Does the except expression need to be general, or would it work
if it were limited to a subclause of variable assignments?
(3b) What about comprehensions?
On Fri Mar 7 20:54:31 CET 2014, Chris Angelico wrote:
>On Sat, Mar 8, 2014 at 5:58 AM, Jim J. Jewett w
On Thu Mar 6 16:52:56 CET 2014, Antoine Pitrou wrote:
> IMO it is absolutely out of question to allow creation of arbitrary
> frames from Python code, because the structure and initialization of
> frames embody too many low-level implementation details.
So?
Does any of that matter until the
On Wed Mar 5 17:37:12 CET 2014, Victor Stinner wrote:
> Python 3 now stores the traceback object in Exception.__traceback__
> and exceptions can be chained through Exception.__context__. It's
> convenient but it introduced tricky reference cycles if the exception
> object is used out of the ex
(Thu Mar 6 23:26:47 CET 2014) Chris Angelico responded:
> On Fri, Mar 7, 2014 at 7:29 AM, Jim J. Jewett wrote:
>> [ note that "x if y" already occurs in multiple contexts, and
>> always evaluates y before x. ]
> Yes, but that's still out of order.
Ye
The PEP currently says:
> Alternative Proposals
> =
> Discussion on python-ideas brought up the following syntax suggestions::
>value = expr except default if Exception [as e]
This one was rejected because of the out-of-order evaluation.
Note, however, that the (fart
Greg Ewing suggested:
>> This version might be more readable:
>>
>> value = lst[2] except "No value" if IndexError
Ethan Furman asked:
> 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?
Yury Selivanov wrote:
> I think the Motivation section is pretty weak.
I have normally wished for this when I was (semi-
interactively) exploring a weakly structured dataset.
Often, I start with a string, split it into something
hopefully like records, and then start applying filters
and tran
Victor Stinner wrote:
>> Will ascii() ever emit an antislash representation?
> Try ascii(chr(0x1f)).
In which version? I get:
ValueError: chr() arg not in range(0x11)
> How do you plan to use this output? Write it into a socket or a file?
> When I debug, I use print & logging w
Greg Ewing replied:
>> ... ASCII compatible binary data is a
>> *subset* of arbitrary binary data.
I 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.
(rough ske
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.
Greg Ewing replied:
> I would say that ASCII compatible binary data is a
> *sub
>> So when it is time to guess [at the character encoding of a file],
>> a source of good guesses is an important battery to include.
> The barrier for entry to the standard library is higher than mere
> usefulness.
Agreed. But "most programs will need it, and people will either
include (the s
101 - 200 of 227 matches
Mail list logo
