On 3/29/23 13:23, Brett Cannon wrote:
Wow, we are now getting Canadian-specific spam!
Since the volume on this mailing list is so low, should we change everyone to be moderated to start and then remove that
after they have posted appropriately? Or did this get through by accident?
Accident.
My apologies for the accidentally accepted spam.
If you reply to that original message, please remove the link before sending.
Thanks. ;-)
--
~Ethan~
___
Python-Dev mailing list -- python-dev@python.org
To unsubscribe send an email to python-dev-le..
Gah. Already dealt with.
___
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
On 12/9/22 09:20, Barry Warsaw wrote:
> The whole shift away from email leaves me calmer and better engaged.
There are definitely advantages to the different methods of staying engaged, and which is the best fit definitely
depends on the individual.
It seems to me the best possible outcome of
On 7/20/22 17:35, Cameron Simpson wrote:
> On 18Jul2022 16:53, Joannah Nanjekye wrote:
>> My original stand on preferring email stands though due to stable
>> standards.
>
> Several of us use the email mode in Discourse. It works quite well. For
> me, both python-dev and the PDO posts land in my
On 7/15/22 08:37, Petr Viktorin wrote:
> And that's exactly why I consume Discourse in mailing list mode, with
client-side
> filtering in Thunderbird.
How do you handle threading? I follow each (sub)thread through to it's end, as it keeps a logical flow, but Discourse
has everything linear wh
On 4/7/22 07:31, Petr Viktorin wrote:
On 07. 04. 22 15:59, Victor Stinner wrote:
Would it be possible to announce new PEPs on python-dev please?
Currently, all PEPs should be announced on python-dev, but not necessarily right after they're published. They should be
announced before submitti
On 4/4/22 10:52, Coyot Linden (Glenn Glazer) wrote:
> On 4/4/22 Guido wondered:
>> How did we get from a specific issue with docstrings and the unittest
package's test
>> reporting to multi-line comments?
>
> Apologies, as I said earlier, I meant to write multiline /string/, not
multiline /comm
[woops]
___
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@p
In the following bit of code:
while s := input.read(MAXBINSIZE):
while len(s) < MAXBINSIZE and ns := input.read(MAXBINSIZE-len(s)):
s += ns
line = binascii.b2a_base64(s)
output.write(line)
I'm getting this error on the second line:
cannot use assignm
[apologies for the late post, just found this in my drafts folder]
On 2/7/22 12:49 AM, Stéfane Fermigier wrote:
3. Overall, I think the days where "battery included" was a positive argument
are over
I strongly disagree. Being able to download something and immediately get something to work
On 3/13/22 14:49, joao.p.f.batista...@gmail.com wrote:
> Currently:
> l = [] # new empty list
> t = () # new empty tuple
> s = set() # new empty set (no clean and consistent way of initializing regarding the
others) <<<
> d = {} # new empty dictionary
>
> Possible solution:
> s = {} # new empty
https://arstechnica.com/information-technology/2022/03/linux-has-been-bitten-by-its-most-high-severity-vulnerability-in-years/
--
~Ethan~
___
Python-Dev mailing list -- python-dev@python.org
To unsubscribe send an email to python-dev-le...@python.org
ht
On 2/10/22 1:45 PM, Brett Cannon wrote:
> Protocols would let folks rely on a common Path object API w/o having to
require the object
> come from pathlib itself or explicitly subclass something (which I admit
would be rare, but
> there's no reason to artificially constrain this either). Now may
On 2/9/22 8:40 AM, Pablo Galindo Salgado wrote:
> Petr Viktorin wrote:
>> Should there be a getter/setter for co_positions?
>
> We consider the representation of co_postions private, so we don't want (for
now) to ad
> getters/setters.
Isn't the whole point of getters/setters is to allow public
On 2/9/22 6:59 AM, Barney Gale wrote:
> Over the last couple of years I've been tidying up the pathlib internals,
with a view
> towards adding an AbstractPath class to the hierarchy. Users would be able to
subclass
> AbstractPath to implement other kinds of filesystems: s3, google cloud
storag
On 2/6/22 6:08 AM, Victor Stinner wrote:
> I propose to deprecate the urllib module in Python 3.11. It would emit
> a DeprecationWarning which warn users, so users should consider better
> alternatives like urllib3 or httpx: well known modules, better
> maintained, more secure, support HTTP/2 (ht
On 2/4/22 6:23 AM, Stefan Behnel wrote:
> One recent example is the new error locations in tracebacks, where PEP 657
explicitly lists
> the new "co_positions" field in code objects as an implementation detail of
CPython. If we
> want to implement this in Cython, then there is no other way than
On 1/31/22 8:47 AM, Lrupert via Python-Dev wrote:
> This gives a bad impression to others about their intentions (constant
contribution of trivial
> / low quality stuff with little-to-no-gain to achieve a higher number of
commits, since it is
> a visible metric).
Two of us have already comment
On 1/29/22 3:14 AM, Lrupert via Python-Dev wrote:
> As someone who is watching the python/cpython repository, I'm very used to
see lots of traffic. But
> lately there have been a surge of spammy PRs which are about the same,
generally very trivial subject
> but individually fixing each occurren
On 1/19/22 1:10 PM, Barry Scott wrote:
> On 18 Jan 2022, at 19:59, Pablo Galindo Salgado wrote:
>> We considered using colours and other markers such as bold text, but that
opens a considerable can of worms with
>> detecting in all systems and configurations if that can be done. I have been
tol
On 1/18/22 11:59 AM, Pablo Galindo Salgado wrote:
> We considered using colours and other markers such as bold text, but that
opens a considerable can of worms with
> detecting in all systems and configurations if that can be done. I have been
told that some of these situations are
> quite tric
On 1/18/22 10:43 AM, Mats Wichmann wrote:
> A thought - how about omitting the underline line if the
> to-be-underlined part would be the whole line?
I would also like that change -- when the underlining is a portion of the whole it's quite useful, but when it's the
whole line it's a lot of ext
On 1/8/22 5:46 PM, Steven D'Aprano wrote:
> [...] if you hate type annotations because they are unreadable, then you
> hate Python because Python is unreadable.
Not so. A simple list comprehension is (usually) quite readable, while a triply-nested list comprehension all on one
line is not.
S
Hello!
The python-dev list is for developing the next version of Python. For help
using Python, please send your question to
python-l...@python.org
Thanks, and good luck!
--
~Ethan~
___
Python-Dev mailing list -- python-dev@python.org
To unsubscr
On 12/13/21 3:34 PM, Steven D'Aprano wrote:
> I think this may be what you are looking for:
[...]
Beat me to it. :-)
--
~Ethan~
___
Python-Dev mailing list -- python-dev@python.org
To unsubscribe send an email to python-dev-le...@python.org
https://
On 12/12/21 10:43 PM, Vioshim wrote:
> Anyways, at the moment that I write this message in python3.10.1, It happens that when making a class with the
dataclasses module, this class can't actually be used in Multiple inheritance for Enum purposes, this is mostly to avoid
code repetition by havin
I ran into an issue today with `str()` not behaving as I thought it should.
Given the following test script, what should happen?
-- 8< --
class Blah(object):
def __str__(self):
return 'blah'
class Huh(int, Blah):
pass
class Hah(Blah, int):
pass
On 11/26/21 1:13 AM, Paul Moore wrote:
> On Fri, 26 Nov 2021 at 05:14, Guido van Rossum wrote:
>>
>> My memory is also hazy, but I'm quite sure that *in my mind* annotations were
>> intended as a compromise between conflicting proposals for *typing*. We
didn't
>> have agreement on the syntax or s
Sorry for the spam -- one of us must have clicked on the wrong button. :-/
--
~Ethan~
Moderator
___
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/pyth
Woops, wrong list -- please disregard.
--
~Ethan~
___
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:/
On 11/11/21 11:53 AM, Matt del Valle wrote:
> Okay, so from the replies so far it looks like this is very quickly going
into the 'never gonna happen'
> dumpster, so in the interests of salvaging *something* out of it:
[...]
> I just dislike having to settle for 'it's what we've got'. With thes
On 11/9/21 9:02 AM, Guido van Rossum wrote:
> On Mon, Nov 8, 2021 at 10:29 PM Ethan Furman wrote:
>> The way I see it, the following should hold
>>
>> empty_flag = RegexFlag(0)
>> any_case = RegexFlag.IGNORECASE
>> any_case_o
On 11/8/21 3:09 PM, Steven D'Aprano wrote:
> On Mon, Nov 08, 2021 at 01:43:03PM -0800, Ethan Furman wrote:
>> SomeFlag.nothing in SomeFlag.something <-- ???
>
> I don't think that consistency with other containers is particularly
> relevant here. More useful
gs are iterable -- `list(F1) == [F1]; list(F1 | F2) == [F1, F2]`
- iterating over a Flag only returns the "pure" (aka single-bit) flags, even if
multi-flag instances
have been created (at least, they will in 3.11)
On 11/8/21 8:32 PM, Guido van Rossum wrote:
> On Mon, Nov 8, 2021
Let's use a concrete example: `re.RegexFlag`
```
Help on function match in module re:
match(pattern, string, flags=0)
Try to apply the pattern at the start of the string, returning
a Match object, or None if no match was found.
```
In use we have:
result = re.match('present', 'who
When is an empty container contained by a non-empty container?
For example:
{} in {1:'a', 'b':2] <-- TypeError because of hashability
set() in {1, 2, 'a', 'b'} <-- ditto
[] in ['a', 'b', 1, 2] <-- False
'' in 'a1b2' <-- True
SomeFlag.nothing in SomeFlag.something <-- ???
Personally,
On 11/8/21 4:45 AM, Victor Stinner wrote:
> Is it implement "like" ascii(obj).encode("ascii") but with minor
> changes? What changes?
It works like `str()`, but you get ascii-encoded bytes (or an exception if
that's not possible).
The difference with the built-in ascii is the absence of extra
On 11/4/21 12:21 PM, Brett Cannon wrote:
> What notification? (I fully admit I may not have gotten one due to some team
I'm in, but I have
> no such notification if it happened recently.)
I've received 20-30 in the last three or four days. I'm not concerned about
it, just providing a data poi
ar).encode('ascii').
The rendered version is at https://www.python.org/dev/peps/pep-0467/
Happy reading!
PEP: 467
Title: Minor API improvements for binary sequences
Version: $Revision$
Last-Modified: $Date$
Author: Nick Coghlan , Ethan Furman
Status: Draft
Type: Standards Track
Cont
: Ethan Furman
Discussions-To: python-dev@python.org
Status: Draft
Type: Informational
Content-Type: text/x-rst
Created: 23-Feb-2013
Python-Version: 3.11
Post-History: 20-Jul-2021, 02-Nov-2021
Resolution:
Abstract
Update the ``repr()``, ``str()``, and ``format()`` of the various Enum
On 10/23/21 8:01 PM, edivmanci...@gmail.com wrote:
> I'm starting now to program with kwant and I'm having problems like:
Sorry, you've reached the wrong list -- this one is for the development of
Python itself.
For general help using Python, subscribe to
python-l...@python.org
which you
On 10/5/21 6:32 PM, MRAB wrote:
> On 2021-10-06 02:12, Barry Warsaw wrote:
>> What do the PEP authors think about `except group`? Bikeshedding aside,
that’s still the best alternative I’ve seen.
>> It’s unambiguous, self-descriptive, and can’t be confused with unpacking
syntax.
>>
> +1
+1
--
On 9/27/21 10:50 AM, Guido van Rossum wrote:
> So my *actual* proposal (call it #2') is to use a separate compile-time flag,
which is set by `./configure
> --enable-optimizations` regardless of whether PGO/LTO are possible, and which
on Windows can be set by
> `PCbuild\build.bat --pgo` (we coul
On 9/24/21 6:51 AM, Eric V. Smith wrote:
> This is clearly an improvement. My question is: is it okay to backport this
to 3.9 and 3.10? I
> think we have a rule that it's okay to change the exception text, but I'm not
sure how that
> applies to micro releases (3.9.x, 3.10.1).
"better" != "bug
Guido:
> It's still an iterator, since it duck-types in most cases where an iterator
> is required (notably "for", which is the primary use case for the iteration
> protocols -- it's in the first sentence of PEP 234's abstract).
D'Aprano:
> I don't think it duck-types as an iterator. Here's an ex
On 9/13/21 9:55 AM, Jelle Zijlstra wrote:
> This table doesn't render properly in
https://www.python.org/dev/peps/pep-0663/#specification.
> - There are some extra blank lines
> - Many cells are blank
> - There are two "user mixed" rows and it's not clear how those relate to the mention of
"thr
On 9/13/21 9:03 AM, Steve Dower wrote:
> You *are* allowed to put some (brief) details in the abstract. No need to
avoid spoilers ;)
>
> As it stands, "it is time" on its own is a really bad reason to change
anything. So you're
> preemptively making it sound like the PEP has no solid backing.
On 9/9/21 12:04 PM, Terry Reedy wrote:
> Except that .to_bytes already exists, and arguably should have had such
defaults from the
> beginning, making any new function to do the same thing superfluous.
New functions aren't always about new functionality; sometimes they are about
increased usab
-Modified: $Date$
Author: Ethan Furman
Discussions-To: python-dev@python.org
Status: Draft
Type: Informational
Content-Type: text/x-rst
Created: 23-Feb-2013
Python-Version: 3.11
Post-History: 20-Jul-2021 10-Sep-2021
Resolution:
Abstract
Now that we have a few years experience with Enum
On 9/9/21 12:12 PM, Barry Warsaw wrote:
> On Sep 9, 2021, at 10:56, Ethan Furman wrote:
>> On 9/9/21 9:37 AM, Barry Warsaw wrote:
>>
>>> While I think int.to_bytes() is pretty obscure (I knew about it, forgot
about it, and learned
>>> about it again!) I’m not so
On 9/9/21 9:37 AM, Barry Warsaw wrote:
> While I think int.to_bytes() is pretty obscure (I knew about it, forgot about
it, and learned
> about it again!) I’m not so sure it’s any less obscure than a proposed
bytes.fromint().
>
> So why don’t we just relax int.to_bytes()’s signature to include n
On 9/9/21 8:53 AM, Christopher Barker wrote:
> On 9/9/21 7:25 AM, Ethan Furman wrote:
>> I'm starting to think the name should be `bytes.bchr` -- it avoids any
confusion with the `int.to_bytes` and
>> `int.from_bytes` methods,
>
> are they so different? :-)
Yes, they
On 9/9/21 1:55 AM, Nick Coghlan wrote:
> `bytes.fromint` is still the inverse of `ord` for bytes objects, even
> without the `bchr` builtin alias. The spelling of the trio is just
> `ord`/`bytes.fromint`/`chr` rather than `ord`/`bchr`/`chr`. The fact
> the method throws an exception for integers
On 9/9/21 3:49 AM, Steven D'Aprano wrote:
> We're Python programmers. To Python programmers, the int 20 is not a
> space character.
That's because int 32 is the space character. ;-)
--
~Ethan~
___
Python-Dev mailing list -- python-dev@python.org
To u
On 9/8/21 1:21 PM, Christopher Barker wrote:
> NOTE: my objection to “bchr”, whether as a builtin or not is not the
functionality, it’s the
> name. Equating a byte with a character is a legacy of C ( and Python 2” — in
Python 3, they
> are completely distinct concepts.
No, they aren't. If you
On 9/7/21 10:39 PM, Steven D'Aprano wrote:
> On Tue, Sep 07, 2021 at 08:09:33PM -0700, Barry Warsaw wrote:
>
>> I think Nick is on board with bytes.fromint() and no bchr(), and my
>> sense of the sentiment here is that this would be an acceptable
>> resolution for most folks. Ethan, can you recon
After reviewing the "Problems with dict subclassing performance" thread, I am suspending Marco Sulla from Python-Dev for
a period of three months. His behavior became blatantly inappropriate, and rather than apologize he continued taunting
those that were trying to help him.
Marco took excepti
Greetings, all!
After petitioning the Steering Council I have been added as a moderator for the Python Dev mailing list. I was already
the moderator of four other Python lists.
My goal as a moderator is to have our forums be civil and within the CoC. I do rely heavily on users to let me know
On 8/3/21 1:19 PM, Barry Warsaw wrote:
> Can you provide some rationale for why you prefer bchr() over .fromint()?
- `bchr` directly corresponds with `chr`
- `str` has no `fromint`
- `bytearray(bchr(int))` is roughly the same as `bytearray.fromint(int)`, but
`bchr(int)` for a bytes object is
On 7/29/21 3:46 PM, Barry Warsaw wrote:
> We’re generally very favorable for adding to Python 3.11 the features and
APIs described
> in the PEP. We have some requests for changes that we’d like you to consider.
>
> * The Python-Version in the PEP needs to target Python 3.11 of course.
Done.
>
On 7/22/21 1:01 AM, Petr Viktorin wrote:
> On 21. 07. 21 14:18, Nick Coghlan wrote:
>>
>> typedef enum {
>> PyLocals_UNDEFINED = -1;
>> PyLocals_DIRECT_REFERENCE = 0,
>> PyLocals_SHALLOW_COPY = 1
>> } PyLocals_Kind;
>>
>> PyLocals_Kind PyLocals_GetKind(void);
>
On 7/21/21 5:33 AM, Nick Coghlan wrote:
> I don't have any substantive comments on what you're proposing (aside
> from "Yes, that sounds reasonable to me"), so my comments below are
> just some minor suggested clarifications for the PEP text.
Thanks, PEP updated.
--
~Ethan~
PEP: 663
Title: Improving and Standardizing Enum str(), repr(), and format() behaviors
Version: $Revision$
Last-Modified: $Date$
Author: Ethan Furman
Discussions-To: python-dev@python.org
Status: Draft
Type: Informational
Content-Type: text/x-rst
Created: 23-Feb-2013
Python-Version: 3.11
Post
On 7/11/21 4:00 PM, Miro Hrončok wrote:
> On 07. 07. 21 3:58, Ethan Furman wrote:
>> I was unable to revert just the str and repr changes in the time available
as many of them were
>> integral to fixes and improvements made to Flag. As a result the enum in
3.10 will be the
On 7/9/21 2:25 PM, Tim Peters wrote:
> `secrets` is just a wrapper around `random.SystemRandom`, so the
> presence or absence of `secrets` doesn't matter.
>
> As to SystemRandom, all answers depend on the quality of the platform
> os.urandom(), which Python has no control over. See my answer here
Greetings!
A question [1] has arisen about the viability of `random.SystemRandom` in Pythons before and after the secrets module
was introduced (3.5 I think) -- specifically
does it give independent and uniform discrete distribution for
cryptographic purposes across CPython 3.x version
On 6/29/21 9:50 AM, Barry Warsaw wrote:
> the Steering Council strongly suggests that for Python 3.10, the changes in
Enum’s
> str and repr be reverted back to the Python 3.9 behavior, and that a PEP be
written
> for Python 3.11.
I was unable to revert just the str and repr changes in the time
On 6/28/21 6:54 AM, Nick Coghlan wrote:
> * Enum repr() changing back to the historical behaviour, unless you opt in to
the
> new behaviour with the global enum decorator: definite +1 here
Question for Nick: this behavior is currently in place for stdlib enumerations, and has been since beta
I have spoken with Pablo (3.10 RM), and he agrees that a change to Enum str() in 3.10 and another in 3.11 is less than
ideal, so this new thread is to collect comments about Enum and it's str() and repr() and whether the changes take
effect in 3.10, 3.11, or both.
TL;DR -- sorry, there isn't on
TL;DR I am considering changing IntEnum and IntFlag's `__str__` to be
`int.__str__`
IntEnum and IntFlag are becoming more common in the stdlib. They currently
show up in
* http
* re
* signal
* ssl
* socket
to name just a few.
3.10 already has some changes to the str() and repr() of enums i
On 6/6/21 9:14 AM, Irit Katriel via Python-Dev wrote:
> On 6 Jun 2021, at 16:58, Andrei Kulakov wrote:
>> In Math / CompSci there is a definition that almost exactly matches this:
Exact Cover -
>> https://en.wikipedia.org/wiki/Exact_cover
>>
>> The difference is that, IIRC, solving the problem i
On 5/27/21 8:24 PM, Ethan Furman wrote:
> So, like the enum.unique decorator that can be used when duplicate names
should be an error,
> I'm adding a new decorator to verify that a Flag has no missing aliased
values that can be
> used when the programmer thinks it's approp
On 5/28/21 12:43 AM, Petr Viktorin wrote:
> On 28. 05. 21 5:24, Ethan Furman wrote:
>> class FlagWithMasks(IntFlag):
>> DEFAULT = 0x0
>>
>> FIRST_MASK = 0xF
>> FIRST_ROUND = 0x0
>> FIRST_CEIL = 0x1
>>
Greetings!
The Flag type in the enum module has had some improvements, but I find it necessary to move one of those improvements
into a decorator instead, and I'm having a hard time thinking up a name.
What is the behavior? Well, a name in a flag type can be either canonical (it represents on
On 5/20/21 10:47 AM, David Mertz wrote:
> On Thu, May 20, 2021 at 6:21 AM Tal Einat wrote:
>> I think it's worth preserving the idiom of comparing sentinels using
>> `is`, as we do for `None` and other existing sentinel values. It's
>> relatively easy to do, such as by using a single-value Enum o
On 5/20/21 11:00 AM, Paul Moore wrote:
> But it nevertheless feels like a bit of an abuse - the original point
> of ellipsis was for indexing, and in particular complex slices like
> a[1:20:2, ..., 3:5]. That usage is common in numpy, as I understand
> it,
Interesting -- do you know what ... mea
On 5/17/2021 6:13 AM, Mark Shannon wrote:
> Where i1, i2 are integers and s1 is a string.
> i1 + i2 + s1
>
Wouldn't the carets just be under the i2 + s1 portion?
--
~Ethan~
___
Python-Dev mailing list -- python-dev@python.org
To unsubscr
On 5/13/21 2:15 AM, Irit Katriel via Python-Dev wrote:
>
> >>> help(traceback.print_exception)
> Help on function print_exception in module traceback:
>
> print_exception(exc, /, value=,
tb= at 0x02825DF09650>, limit=None, file=None,
chain=True)
On
On 5/9/21 3:00 AM, M.-A. Lemburg wrote:
> BTW: For better readability, I'd also not output the lines
> for every stack level in the traceback, but just the last one,
> since it's usually clear where the call to the next stack
> level happens in the upper ones.
Usually, sure -- but in the un
On 5/8/21 1:31 PM, Pablo Galindo Salgado wrote:
>> We can't piggy back on -OO as the only way to disable this, it needs to
>> have an option of its own. -OO is unusable as code that relies on "doc"
>> strings as application data such as http://www.dabeaz.com/ply/ply.html
>> exists.
>
> -OO is the
On 5/6/21 7:14 AM, Jelle Zijlstra wrote:
> Maybe others have different workflows, but I don't see much of a need
> for keeping your fork's main branch up to date.
I will occasionally do a `git push origin main` just to shut up the messages about being behind/ahead; other than that,
I have no id
I have two pull requests against my cpython fork from a dependabot -- what is
that, and should I merge them?
--
~Ethan~
___
Python-Dev mailing list -- python-dev@python.org
To unsubscribe send an email to python-dev-le...@python.org
https://mail.python
On 4/29/21 7:57 PM, Larry Hastings wrote:
> When one writes one's "blurb" for the changelog, in what tense should it be?
Present tense. :)
--
~Ethan~
___
Python-Dev mailing list -- python-dev@python.org
To unsubscribe send an email to python-dev-le..
On 4/29/21 10:35 AM, Jonathan Goble wrote:
> On Thu, Apr 29, 2021 at 1:20 PM Ethan Furman wrote:
>> Which raises the question: Do we want to have a standard name for stdlib
Flags when no flags are set?
>
> If you want a flag to represent no flags set, it takes one line to wri
On 4/29/21 10:52 AM, Antoine Pitrou wrote:
> On Thu, 29 Apr 2021 18:37:29 +0100, MRAB wrote:
>> On 2021-04-29 18:19, Ethan Furman wrote:
>>> An excerpt from bpo-31369: re.RegexFlag and `__all__`
>>>
>>> GvR:
>>>
>>>> One thing
An excerpt from bpo-31369: re.RegexFlag and `__all__`
GvR:
> One thing I discovered when developing this example: there doesn't seem to be
a flag to
> represent 0 (zero), i.e. "no flags". And foo(0) is a type error (even though
it works
> fine at runtime).
Which raises the question: Do
On 4/20/21 2:11 PM, MRAB wrote:
> On 2021-04-20 20:42, Ethan Furman wrote:
>> The deprecation period will give that user, and others like them, time to
add their own Enum base classes with the
>> `__format__` method they desire.
>
> Couldn't the format accept '
On 4/20/21 12:01 PM, Guido van Rossum wrote:
> On Tue, Apr 20, 2021 at 11:12 AM Ethan Furman wrote:
>> Moving forward, I'm not sure having format() and str() ever be different
>> is a good idea, especially since users who need, for example, Color.RED
>> to be '1&#
On 4/20/21 8:46 AM, Guido van Rossum wrote:
I'd guess it is totally up to the object, since str() calls `__str__` and format() calls `__format__`. Of course this
now begs the question whether those enums should perhaps change their `__format__` to match their `__str__`...?
When Enum was design
urllib.urlencode currently uses `str()` on its non-bytes objects before encoding the result. This causes a
compatibility break when integer module constants are converted to IntEnum, as `str(IntEnum.MEMBER)` no longer returns
the integer representation; however, `format()` does still return the
On 4/19/21 10:51 AM, Larry Hastings wrote:
Something analogous /could/ happen in the PEP 649 branch but currently doesn't. When running Inada Noki's benchmark,
there are a total of nine possible annotations code objects. Except, each function generated by the benchmark has a
unique name, and
On 4/16/21 10:43 AM, redrad...@gmail.com wrote:
Take a look at this video https://www.youtube.com/watch?v=D7Sd8A6_fYU
or read some articles ... otherwise I will need to spend too many time
providing evidences to you and after all you will probably will reject anyway
(because lots of people is
On 4/16/21 10:27 AM, redrad...@gmail.com wrote:
Chris Angelico wrote:
On Sat, Apr 17, 2021 at 3:20 AM redrad...@gmail.com wrote:
The benefits:
You will link with high quality libstdc++ with lots of reusable containers without
writing your own "buggy" one.
C++ is much much more maintainable th
On 4/13/21 6:20 PM, Inada Naoki wrote:
Then, does anyone oppose this change?
Having staticmethod, etc., be callable would make my code much easier in at
least two different projects.
Please make this change.
--
~Ethan~
___
Python-Dev mailing list
On 4/13/21 3:01 PM, Jelle Zijlstra wrote:
Thanks for this PEP! Most of these proposals would make for useful improvements to the language. I have a few pieces of
feedback below.
El mar, 13 abr 2021 a las 14:14, Ethan Furman escribió:
This PEP has been deferred until Python 3.9 at the
-Modified: $Date$
Author: Nick Coghlan , Ethan Furman
Status: Deferred
Type: Standards Track
Content-Type: text/x-rst
Created: 30-Mar-2014
Python-Version: 3.9
Post-History: 2014-03-30 2014-08-15 2014-08-16 2016-06-07 2016-09-01 2021-04-13
Abstract
During the initial development of the
> You could say [...] or "I deeply think that this was one of the
> worst decisions" [...]
Not to get too far off topic, but that's not a good choice of words, either.
--
~Ethan~
___
Python-Dev mailing list -- python-dev@python.org
To unsubscribe send
On 4/8/21 1:43 PM, Antoine Pitrou wrote:
On Thu, 8 Apr 2021 13:31:26 -0700
Ethan Furman wrote:
```python
from tempfile import NamedTemporaryFile
with NamedTemporaryFile() as fp:
fp.write(b'some data')
fp.close() # Windows workaround
fp.open()
data = fp.read
In issue14243 [1] there are two issues being tracked:
- the difference in opening shared files between posix and Windows
- the behavior of closing the underlying file in the middle of
NamedTemporaryFile's context management
I'd like to address and get feedback on the context management issue.
1 - 100 of 1590 matches
Mail list logo
