Re: [Python-Dev] PEP 557: Data Classes

[Jonathan Goble]

Interesting. I note that this under "Specification":

"""
field's may optionally specify a default value, using normal Python syntax:

@dataclass
class C:
int a   # 'a' has no default value
int b = 0   # assign a default value for 'b'
"""

...does not look like "normal Python syntax".

On Fri, Sep 8, 2017 at 11:44 AM Eric V. Smith  wrote:

> Oops, I forgot the link. It should show up shortly at
> https://www.python.org/dev/peps/pep-0557/.
>
> Eric.
>
> On 9/8/17 7:57 AM, Eric V. Smith wrote:
> > I've written a PEP for what might be thought of as "mutable namedtuples
> > with defaults, but not inheriting tuple's behavior" (a mouthful, but it
> > sounded simpler when I first thought of it). It's heavily influenced by
> > the attrs project. It uses PEP 526 type annotations to define fields.
> > From the overview section:
> >
> > @dataclass
> > class InventoryItem:
> > name: str
> > unit_price: float
> > quantity_on_hand: int = 0
> >
> > def total_cost(self) -> float:
> > return self.unit_price * self.quantity_on_hand
> >
> > Will automatically add these methods:
> >
> >   def __init__(self, name: str, unit_price: float, quantity_on_hand: int
> > = 0) -> None:
> >   self.name = name
> >   self.unit_price = unit_price
> >   self.quantity_on_hand = quantity_on_hand
> >   def __repr__(self):
> >   return
> > f'InventoryItem(name={self.name
> !r},unit_price={self.unit_price!r},quantity_on_hand={self.quantity_on_hand!r})'
> >
> >   def __eq__(self, other):
> >   if other.__class__ is self.__class__:
> >   return (self.name, self.unit_price, self.quantity_on_hand) ==
> > (other.name, other.unit_price, other.quantity_on_hand)
> >   return NotImplemented
> >   def __ne__(self, other):
> >   if other.__class__ is self.__class__:
> >   return (self.name, self.unit_price, self.quantity_on_hand) !=
> > (other.name, other.unit_price, other.quantity_on_hand)
> >   return NotImplemented
> >   def __lt__(self, other):
> >   if other.__class__ is self.__class__:
> >   return (self.name, self.unit_price, self.quantity_on_hand) <
> > (other.name, other.unit_price, other.quantity_on_hand)
> >   return NotImplemented
> >   def __le__(self, other):
> >   if other.__class__ is self.__class__:
> >   return (self.name, self.unit_price, self.quantity_on_hand) <=
> > (other.name, other.unit_price, other.quantity_on_hand)
> >   return NotImplemented
> >   def __gt__(self, other):
> >   if other.__class__ is self.__class__:
> >   return (self.name, self.unit_price, self.quantity_on_hand) >
> > (other.name, other.unit_price, other.quantity_on_hand)
> >   return NotImplemented
> >   def __ge__(self, other):
> >   if other.__class__ is self.__class__:
> >   return (self.name, self.unit_price, self.quantity_on_hand) >=
> > (other.name, other.unit_price, other.quantity_on_hand)
> >   return NotImplemented
> >
> > Data Classes saves you from writing and maintaining these functions.
> >
> > The PEP is largely complete, but could use some filling out in places.
> > Comments welcome!
> >
> > Eric.
> >
> > P.S. I wrote this PEP when I was in my happy place.
> >
> ___
> 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/jcgoble3%40gmail.com
>
___
Python-Dev mailing list
Python-Dev@python.org
https://mail.python.org/mailman/listinfo/python-dev
Unsubscribe: 
https://mail.python.org/mailman/options/python-dev/archive%40mail-archive.com

Re: [Python-Dev] PEP 540: Add a new UTF-8 mode (v2)

[Jonathan Goble]

On Thu, Dec 7, 2017 at 8:38 PM Glenn Linderman 
wrote:

> If it were to be changed, one could add a text-mode option in 3.7, say "t"
> in the mode string, and a PendingDeprecationWarning for open calls without
> the specification of either t or b in the mode string.
>

"t" is already supported in open()'s mode argument [1] as a way to
explicitly request text mode, though it's essentially ignored right now
since text is the default anyway. So since the option is already present,
the only thing needed at this stage for your plan would be to begin
deprecating not using it.

*goes back to lurking*

[1] https://docs.python.org/3/library/functions.html#open
___
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] Broken svn lookup?

[Jonathan Goble]

On Mon, Dec 18, 2017 at 9:57 AM Victor Stinner 
wrote:

> Hi,
>
> I was looking at old issues. In
> https://bugs.python.org/issue8610#msg105805 I found the link:
>
>   http://svn.python.org/view?view=revision&revision=81190
>
> Sadly, the link fails with HTTP 404 Not Found :-(
>
> Is the service down? It's no more possible to browse the old
> Subversion repository?
>

I don't get a 404 response. I get a Firefox dialog box asking for my
username and password, and on clicking "Cancel", I then get an HTTP 401
Unauthorized response.
___
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] in

[Jonathan Goble]

On Tue, Apr 3, 2018 at 7:34 PM 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?
>

If I had to hazard a guess, I'd say it's because strings by definition, in
the sense that they are a container, can only contain strings of length 1,
whereas the other containers you listed can contain a wide variety of
Python objects (in some cases, any Python object). Thus it's easy to detect
and raise the TypeError.

Note that `[] in set()` also raises TypeError, so it's consistent: values
of types that are impossible for the container to contain generally raise
TypeError (in this case, an unhashable type and a container that only
accepts hashable types).

(I may be oversimplifying this a bit, but I think the basic idea is right.)
___
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] Introducing python.zulipchat.com

[Jonathan Goble]

On Sat, Apr 21, 2018, 4:51 AM Paul Moore  wrote:

> Just a usability note - the sign in procedure seems very weird. I
> tried to log in, but didn't want to create another independent account
> so I tried "Sign in with Google" and "Sign in with Github". Both took
> me round a loop of authorising the access, then said "no account found
> for your email address" and I ended up back at the sign in page.
>
> I'm not sure what I did wrong, but the first time I did this, I just
> gave up. This time, I've sent this message...
>

Try clicking on "Sign up" below those buttons to get the "sign up with
Google/GitHub" buttons.

>
___
Python-Dev mailing list
Python-Dev@python.org
https://mail.python.org/mailman/listinfo/python-dev
Unsubscribe: 
https://mail.python.org/mailman/options/python-dev/archive%40mail-archive.com

[Python-Dev] Regular expression bytecode

[Jonathan Goble]

I'm new to Python's mailing lists, so please forgive me if I'm sending
this to the wrong list. :)

I filed http://bugs.python.org/issue26336 a few days ago, but now I
think this list might be a better place to get discussion going.
Basically, I'd like to see the bytecode of a compiled regex object
exposed as a public (probably read-only) attribute of the object.

Currently, although compiled in pure Python through modules
sre_compile and sre_parse, the list of opcodes is then passed into C
and copied into an array in a C struct, without being publicly exposed
in any way. The only way for a user to get an internal representation
of the regex is the re.DEBUG flag, which only produces an intermediate
representation rather than the actual bytecode and only goes to
stdout, which makes it useless for someone who wants to examine it
programmatically.

I'm sure others can think of other potential use cases for this, but
one in particular would be that someone could write a debugger that
can allow a user to step through a regex one opcode at a time to see
exactly where it is failing. It would also perhaps be nice to have a
public constructor for the regex object type, which would enable users
to modify the bytecode and directly create a new regex object from it,
similar to what is currently possible through the types.FunctionType
and types.CodeType constructors.

In addition to exposing the code in a public attribute, a helper
module written in Python similar to the dis module (which is for
Python's own bytecode) would be very helpful, allowing the code to be
easily disassembled and examined at a higher level.

Is this a good idea, or am I barking up the wrong tree? I think it's a
great idea, but I'm open to being told this is a horrible idea. :) I
welcome any and all comments both here and on the bug tracker.

Jonathan Goble
___
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] Regular expression bytecode

[Jonathan Goble]

On Sun, Feb 14, 2016 at 2:41 PM, Franklin? Lee
 wrote:
> I think it would be nice for manipulating (e.g. optimizing, possibly with
> JIT-like analysis) and comparing regexes. It can also be useful as a
> teaching tool, e.g. exercises in optimizing and comparing regexes.

Both great points in favor of this.

> I think the discussion should be on python-ideas, though.

Thanks for being gentle with the correction. :) I'll resend it over
there later tonight when I have some more time on my hands.
___
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] Regular expression bytecode

[Jonathan Goble]

On Fri, Feb 19, 2016 at 2:30 PM, Simon Cross
 wrote:
> This might be tricky for alternative Python implementations which
> might compile regular expressions into something rather different.

As has been discussed on python-ideas, it would be explicitly treated
as a CPython implementation detail, so that wouldn't be an issue.

That said, I've decided to shelve the idea for the time being, at
least, as I've had some things come up unexpectedly, and I no longer
have time to pursue this.
___
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] What does a double coding cookie mean?

[Jonathan Goble]

On Wed, Mar 16, 2016 at 2:07 AM, Chris Angelico  wrote:
> Why would you ever have two coding cookies in a file? Surely this
> should be either an error, or ill-defined (ie parsers are allowed to
> pick whichever they like, including raising)?
>
> ChrisA

+1. If multiple coding cookies are found, and all do not agree, I
would expect an error to be raised. That it apparently does not raise
an error currently is surprising to me.

(If multiple coding cookies are found but do agree, perhaps raising a
warning would be a good idea.)
___
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] Challenge: Please break this! (a.k.a restricted mode revisited)

[Jonathan Goble]

On Sun, Apr 10, 2016 at 7:02 PM, Oscar Benjamin
 wrote:
> I haven't looked at your sandbox but for a different approach try this one:
>
>   L = [None]
>   L.extend(iter(L))
>
> On my Linux machine that doesn't just crash Python.

For the record: don't try this if you have unsaved files open on your
computer, because you will lose them. When I typed these two lines
into the Py3.5 interactive prompt, it completely and totally froze
Windows to the point that nothing would respond and I had to resort to
the old trick of holding the power button down for five seconds to
forcibly shut the computer down.

Fortunately, I made extra certain everything was fully saved before I
opened the Python interpreter, so I'm not TOTALLY dumb. :-P
___
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] A "day of silence" on PEP 572?

[Jonathan Goble]

On Fri, Jul 6, 2018, 3:41 PM Antoine Pitrou  wrote:

>
> I would gladly welcome a PEP 572-less development mailing-list.
>

+1.

Speaking as a lurker with little interest in the particular topic, PEP 572
has almost driven me to unsubscribe. It's not the massive number of posts
that is annoying, but the fact that seemingly (perhaps literally?) scores
of separate threads have been created for it. A single thread, or a small
number of threads, are easily muted, but when multiple new threads are
created seemingly daily or weekly for months on end, trying to gain control
of my inbox feels like an endless game of Whac-A-Mole [1] with no prizes,
and that's not a good thing.

[1] Being a global list, here's a link for anyone not familiar with the
game: https://en.m.wikipedia.org/wiki/Whac-A-Mole

>
___
Python-Dev mailing list
Python-Dev@python.org
https://mail.python.org/mailman/listinfo/python-dev
Unsubscribe: 
https://mail.python.org/mailman/options/python-dev/archive%40mail-archive.com

Re: [Python-Dev] PEP 572: Assignment Expressions -- intention to accept, near-final draft

[Jonathan Goble]

On Tue, Jul 10, 2018 at 2:00 AM Terry Reedy  wrote:

> On 7/9/2018 9:00 PM, Guido van Rossum wrote:
> > We strongly prefer feedback in the form of Pull Requests to the peps
> > repo (the file is at
> > https://github.com/python/peps/blob/master/pep-0572.rst
> > ).
>
> I couple of people have said they don't know how to make pull requests
> against a PEP.  I believe the following works with the web editor.
>
> 1. Go to url above.
> 2. Click upper right pencil icon.  I don't know just who can do this.
> 3. Edit on the web page.  It might be easier to read the html and then
> use browser find to change anything seen.
> 4. Note that there are two scrollbars -- one for webpage and one for
> editing box.
> 5. At the bottom of the webpage, click 'Create a new branch for this
> commit and start a PR'.  This should unclick 'Commit directly to the
> master branch.'
> 6. Click Green [Propose file change] button.
> 7. I expect one will end up on the PR diff page.  If not, click 'files
> changed to get there.  Add comments explaining changes that need such.
>

This is almost precisely how I, a newbie to contributing, fixed a typo in
this PEP tonight. At step 2, anyone who is logged in can click the pencil
icon; if you don't have write access to the repo, GitHub automatically
forks the repo and commits your change to a new branch within your fork,
eliminating step 5.

The problem I see with this is that I don't know of any way to accept or
> reject the different proposed changes within the PR.  If there is, I
> would like to know how.
>

I don't believe there is a way to merge part of a PR. The rejected changes
would have to be reverted with a new commit prior to merging.

-- 
> Terry Jan Reedy
>
> ___
> 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/jcgoble3%40gmail.com
>
___
Python-Dev mailing list
Python-Dev@python.org
https://mail.python.org/mailman/listinfo/python-dev
Unsubscribe: 
https://mail.python.org/mailman/options/python-dev/archive%40mail-archive.com

Re: [Python-Dev] switch statement

[Jonathan Goble]

As Michael said, this belongs on python-ideas, but it's interesting. I'd
support it, though my input in that regard is worth approximately $0.00. ;)
It's the core devs and especially the eventual BDFL replacement whom you
would have to convince.

Without getting into an extended discussion here on python-dev, I'd like to
offer one brief comment to try to help improve the proposal:

On Fri, Sep 21, 2018 at 2:17 PM  wrote:

> Let allow fallthrough or not? - To be decided. (Either is compatible with
> the above.)
>

I would argue for non-fallthrough as the default with support for
explicitly requesting fallthrough when desired by using "continue". I don't
know of any prior art for doing it that way, but it makes sense to me. It
eliminates hidden bugs from missing a "break" while still allowing it when
needed.

Good luck with the proposal!
___
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] Summary of Python tracker Issues

[Jonathan Goble]

On Thu, Feb 28, 2019, 8:02 AM INADA Naoki  wrote:

> No stats for last week?
>

Been missing for two weeks actually. I did not receive a summary on either
the 15th or 22nd.

>
___
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] Summary of Python tracker Issues

[Jonathan Goble]

On Thu, Feb 28, 2019, 5:11 PM Terry Reedy  wrote:

> On 2/28/2019 8:07 AM, Jonathan Goble wrote:
> > On Thu, Feb 28, 2019, 8:02 AM INADA Naoki  > <mailto:songofaca...@gmail.com>> wrote:
> >
> > No stats for last week?
> >
> >
> > Been missing for two weeks actually. I did not receive a summary on
> > either the 15th or 22nd.
>
> Ditto for me.  I get pydev via gmane.  Anyone missing the same issues
> get pydev directly by email?
>

I get direct emails only and stated my observation above. :-)

>
___
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] Summary of Python tracker Issues

[Jonathan Goble]

On Thu, Feb 28, 2019 at 6:57 PM Glenn Linderman 
wrote:

> On 2/28/2019 2:52 PM, Terry Reedy wrote:
>
> On 2/28/2019 5:38 PM, Glenn Linderman wrote:
>
> On 2/28/2019 2:18 PM, Jonathan Goble wrote:
>
> On Thu, Feb 28, 2019, 5:11 PM Terry Reedy  <mailto:tjre...@udel.edu> > wrote:
>
> On 2/28/2019 8:07 AM, Jonathan Goble wrote:
> > On Thu, Feb 28, 2019, 8:02 AM INADA Naoki
> mailto:songofaca...@gmail.com>
> 
> > <mailto:songofaca...@gmail.com 
> <mailto:songofaca...@gmail.com> >>
> wrote:
> >
> > No stats for last week?
> >
> >
> > Been missing for two weeks actually. I did not receive a summary on
> > either the 15th or 22nd.
>
> Ditto for me.  I get pydev via gmane.  Anyone missing the same issues
> get pydev directly by email?
>
>
> I get direct emails only and stated my observation above. :-)
>
>
> I confirm and concur with Jonathan's observation, by searching my email
> archive for this group list. So it is not just something about his
> particular email address... except we both do use Google Mail services.  I
> do check my Google SPAM box for the account, and it wasn't there either, by
> recollection (I don't archive the SPAM, but delete it ASAP).
>
> Can someone not using a Google email address also confirm?
>
>
> I effectively did when I said I access via gmane -- as a newsgroup via
> NNTP.  I am sure that the mail server sends directly to news.gmane.org
> rather than through google.
>
>
> That's a whole different protocol. I don't know all the configurations for
> the server that sends the Summary messages, or how it is handled, but you
> confirm it didn't get to gnane via NNTP, and Jonathan and I confirm it
> didn't get to Google email servers, but neither one really confirms that it
> didn't get to other email servers. Google email is definitely different
> than other email servers.
>
> There seems to be enough evidence that something went wrong somewhere,
> though, and whoever maintains that process should start investigating, but
> it would still be nice to get confirmation from a non-Google email
> recipient whether they did or did not get the Summary messages.
>
> I wonder if there is a way to manually send them, and if the missing two
> weeks of activity can be reported... once the sending problem is understood
> and resolved.
>

It's also possible that the fault is not in sending (we have evidence here
that two entirely different protocols have not received it, and they are
also not in the archives [1]), but in the generation of the report. Could
there have been a subtle change to the bpo tracker itself, or something
else along those lines, that is causing the script to fail silently before
it ever reaches the point of attempting to send? Or perhaps a disk ran out
of space somewhere?

[1] https://mail.python.org/pipermail/python-dev/2019-February/date.html
___
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] Is XML serialization output guaranteed to be bytewise identical forever?

[Jonathan Goble]

On Thu, Mar 21, 2019, 1:05 PM Steve Holden  wrote:

> On Thu, Mar 21, 2019 at 11:33 AM Antoine Pitrou 
> wrote:
>
>> [...]
>>
>> Most users and applications should /never/ care about the order of XML
>> attributes.
>>
>> Regards
>>
>> Antoine
>>
>
> Especially as the standards specifically say that ordering has no semantic
> impact.
>

When you have a lot of attributes, though, sometimes having them in a
particular defined order can make it easier to reason about and make sense
of the code when manually reviewing it.

>
___
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] A request for PEP announcement format [was: PEP 570]

[Jonathan Goble]

On Thu, Mar 28, 2019 at 11:11 PM Stephen J. Turnbull <
turnbull.stephen...@u.tsukuba.ac.jp> wrote:

>  >
> https://discuss.python.org/t/pep-570-Python-Positional-Only-Parameters/1078
>
> (sorry, case changed for emphasis so clicking won't work)
>

Clicking actually did work for me. Not only is that portion of the link not
case-sensitive, but it doesn't even matter what it is or if it's present at
all. https://discuss.python.org/t/pep-570-fgfdgfdgdfgd-parameters/1078 and
https://discuss.python.org/t/1078 both lead to the same thread, but if I
change the number at the end to 1077, I get a different thread.

So the system only uses the number at the end to identify the thread, and
the text is strictly for the benefit of human readability and not parsed by
the server. File that in the "probably useless information" category of
your brain. ;-)

*goes back to lurking*
___
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] Online Devguide mostly not working

[Jonathan Goble]

Confirming that I also cannot access the Getting Started page. I'm in
Ohio, if it matters.

On Sat, May 11, 2019 at 6:26 PM Terry Reedy  wrote:
>
> https://devguide.python.org gives the intro page with TOC on sidebar and
> at end.  Clicking anything, such as Getting Started, which tries to
> display https://devguide.python.org/setup/, returns a Read the Docs page
> "Sorry This page does not exist yet."  'Down for everyone' site also
> cannot access.
>
> --
> Terry Jan Reedy
>
> ___
> 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/jcgoble3%40gmail.com
___
Python-Dev mailing list
Python-Dev@python.org
https://mail.python.org/mailman/listinfo/python-dev
Unsubscribe: 
https://mail.python.org/mailman/options/python-dev/archive%40mail-archive.com

[Python-Dev] Re: Enum and annotations

[Jonathan Goble]

On Mon, Jun 10, 2019 at 6:44 PM Steve Dower  wrote:
>
> I'd expect people coming from other languages to get it wrong this way too:
>
> class Status(Enum):
>  on
>  off
>
> Which will of course raise NameError and be just as opaque to the naive
> user as the AttributeError later on. I'm not sure we can do as much to
> help this case, but perhaps we can update __getattr__ to check
> __annotations__ on the class before failing and provide a clearer
> message? e.g. "AttributeError: 'on' was specified without assigning a
> value, did you use ':' instead of '='?" Or we could do this on
> construction, but that may rule out some interesting uses in the future
> if you have a need to delay specifying enum values.

As a side note, the aenum package on PyPI [1] supports this bare-name
notation with its AutoNumberEnum class, which uses some metaclass
magic to do it. aenum's code is complex, but an extremely bare-bones
version can be written in about 15 lines of code:

```
class AutoNumberDict(dict):
def __init__(self, *args, **kwargs):
super().__init__(*args, **kwargs)
self.count = 0

def __missing__(self, key):
if isinstance(key, str) and key.startswith('__') and key.endswith('__'):
raise KeyError(key)
self[key] = self.count
self.count += 1

class EnumType(type):
def __prepare__(name, bases):
return AutoNumberDict()

class Enum(metaclass=EnumType):
pass
```

Of course, there are some cases that this doesn't handle (such as
duplicate names or bit flags), but for a one-off script or a personal
project, it could be enough.

[1] https://pypi.org/project/aenum/
___
Python-Dev mailing list -- python-dev@python.org
To unsubscribe send an email to python-dev-le...@python.org
https://mail.python.org/mailman3/lists/python-dev.python.org/
Message archived at 
https://mail.python.org/archives/list/python-dev@python.org/message/CJIWLLZ2JEN2TH4B33PNWXFBN4OAOSSD/

[Python-Dev] [Possibly off-topic] Python-Announce floods and delays

[Jonathan Goble]

(I don't know the best list to post this to, so if this is not it,
please forgive me and point me in the right direction. Thanks.)

So my inbox, and probably many of yours, was flooded this afternoon
with a dozen-plus emails from the Python-Announce list. I understand
that this list requires every email to be manually approved by a
moderator. The problem is that this is done infrequently. Prior to
today, the last round of approvals was June 26, almost two weeks ago.
This is not an atypical delay; on the contrary, it seems that
moderators only look at the queue once every one to two weeks.

There are several problems with these delays:

1. They result in floods of emails, with a large number of emails in a
short period of time. This makes inbox management difficult on the
days that approvals are done. Before you argue that "it's fine if you
have the right tools configured in the right way", consider that there
are probably many people who are subscribed to Python-Announce who
have no interest in and are not subscribed to any of the actual
discussion lists where such tools are most beneficial. Complex tool
configurations should not be a requirement for managing incoming
emails from what is essentially (to those people) a notification-only
mailing list. These people would be better served by frequent
approvals several times a week, allowing them to get fewer emails at
one time, but in a more timely manner.

2. Speaking of a more timely manner, the lengthy delays result in
redundant and outdated emails going through after the point where they
are no longer relevant. One such issue exemplified by today's set of
approvals (and seen on previous occasions before) is an announcement
of a new release of a PyPI package not being approved until after
there has already been a subsequent release to that same package. In
this case I am referring to the pytest 5.0.0 announcement sent to the
list on June 28 (according to the headers), followed by the pytest
5.0.1 announcement sent to the list on July 5. Neither was approved
and delivered to subscribers until today.

3. More importantly in terms of delays, on July 3 an announcement was
sent to the list regarding the impending switch of EuroPython ticket
rates to the late registration rate on July 6. This is an example of a
time-sensitive announcement that needs to not be delayed. Instead, the
email was not approved and delivered to subscribers until today, July
8, after the conference has already begun, and not in time for list
subscribers to react and avoid the late registration rates.

Is there a solution to this that would enable moderators to approve
more frequently? I understand that they are probably volunteers and
need to find spare time to wade through the queue, but if approvals
are done more frequently (even daily), then it will consume much less
time on each occasion. It would go from a task requiring an entire
hour (as it apparently did today based on the delivery timestamps) to
something that can be done on a coffee break.
___
Python-Dev mailing list -- python-dev@python.org
To unsubscribe send an email to python-dev-le...@python.org
https://mail.python.org/mailman3/lists/python-dev.python.org/
Message archived at 
https://mail.python.org/archives/list/python-dev@python.org/message/XOQZK7KNXNUC2EC65FDDX7GSMLUUHHDU/

[Python-Dev] Re: [Possibly off-topic] Python-Announce floods and delays

[Jonathan Goble]

On Mon, Jul 8, 2019, 3:56 PM Barry Warsaw  wrote:

> On Jul 8, 2019, at 12:27, Jonathan Goble  wrote:
>
> > Is there a solution to this that would enable moderators to approve
> > more frequently?
>
> Volunteers are welcome! :)
>
> -Barry
>

I'd offer to volunteer, but I am merely a lurker and not active in the
community, and I feel like someone more active and known in the community
should take that role. Speaking of which, it looks like an -ideas mod has
volunteered for -announce, so maybe that will help. :)

>
___
Python-Dev mailing list -- python-dev@python.org
To unsubscribe send an email to python-dev-le...@python.org
https://mail.python.org/mailman3/lists/python-dev.python.org/
Message archived at 
https://mail.python.org/archives/list/python-dev@python.org/message/DIPEU26LK5JE5B2QH3LSHVSC44FGDMP7/

[Python-Dev] Re: [Possibly off-topic] Python-Announce floods and delays

[Jonathan Goble]

On Mon, Jul 8, 2019 at 5:23 PM Barry Warsaw  wrote:
>
> On Jul 8, 2019, at 12:56, Barry Warsaw  wrote:
>
> > Volunteers are welcome! :)
>
> Wow, that was fast!  Thanks for the offers for help.  I’ll add everyone who’s 
> stepped up so far to the list moderators.  Yes, you do get a notification 
> every day with a link right to the moderation page.
>
> Cheers,
> -Barry

I'll echo the "wow". :) Happy to see people jumping at the chance to
help. Hopefully this leads to quicker moderation (which seems likely)
that doesn't flood inboxes like today.

As for me, I'll continue to lurk and learn as I continue my sophomore
year as a college student majoring in computer science, with hopes of
becoming more active in contributing to Python as I gain more
experience and skills.

Thanks everyone! :D
___
Python-Dev mailing list -- python-dev@python.org
To unsubscribe send an email to python-dev-le...@python.org
https://mail.python.org/mailman3/lists/python-dev.python.org/
Message archived at 
https://mail.python.org/archives/list/python-dev@python.org/message/2OAJ35YVR6N54O6WKJE6OQ2CBUGWUJQH/

[Python-Dev] Re: OT: Other fun contribution [was: Python-Announce floods and delays]

[Jonathan Goble]

On Tue, Jul 9, 2019 at 12:35 AM Stephen J. Turnbull
 wrote:
>
> Jonathan Goble writes:
>
>  > As for me, I'll continue to lurk and learn as I continue my sophomore
>  > year as a college student majoring in computer science, with hopes of
>  > becoming more active in contributing to Python as I gain more
>  > experience and skills.
>
> Evidently you have ambition to acquire a "commit bit".  That's a
> worthy goal (heaven knows we need more reviewers!),

Ha, I don't have any kind of grand ambitions like that (at least not
yet). To date I've contributed exactly one commit, that being a
trivial typo fix in a PEP. My real goal is get to the point in a year
or two where I can periodically contribute non-trivial code to fix
real bugs and such, but I'm going through a major transition right now
(graduating community college and transferring to a four-year
university next month) and don't have the spare time to wade in
currently. I also haven't taken any real computer courses yet other
than a basic freshman-level Java sequence, so my general skills are
lacking, but this upcoming academic year is when I will get elbow-deep
in the more advanced courses, including algorithms, so once I settle
in to the university over the next few months I plan to try to
contribute more.

> but there are
> plenty of other ways to contribute.  Some of the obvious ones (like
> documentation and teaching) may not be your thing, but there's
> probably a PyCon or Python meetup near you.  Especially for the larger
> ones, there are all kinds of "social volunteer" tasks, such as swag
> bag stuffing and registration desk, where even an hour or so of
> contribution is appreciated and you can interact with other people who
> are there for the same reasons you are.

I cannot afford a lot of travel, and as a college student, I have
limited dates to do so. For example, this year's PyCon was
inaccessible to me despite living "nearby" in Southwest Ohio partially
because of inability to afford gas and a hotel, but more importantly,
because it was held during final exam week. Next year's PyCon, a
similar distance away, will be during the last week of classes before
final exams, so I can't attend it either. I wish I could, but the
schedules don't work. From a financial perspective, even a single
night in a hotel is something I have to plan and budget for at least a
month or two in advance.

> (Beware: volunteering can be
> addictive, and you may find yourself running for PSF Board before you
> know it!)

The day that happens will be the day hell freezes over. :P

> "Contribution" doesn't have to involve "skills" or deskwork, and
> everyone can find ways that are lots of fun for them!
>
> Steve

What's fun for me is writing code. ;) When I have the free time (which
isn't much lately), I like to play around with writing random personal
projects, a couple of which I have published rough betas to PyPI (that
probably have been downloaded by nobody except me). I need to find
time between semesters to sit down and polish some of them up to
create a portfolio for internship applications, and I'm sure that the
next year of college will help me improve the quality significantly.

That said, if I could get to a PyCon or other meetup (which is a
function of both money and scheduling), I would be more than willing
to sign up for a volunteer shift. The difficulty is getting there
without disrupting my education or breaking the bank.
___
Python-Dev mailing list -- python-dev@python.org
To unsubscribe send an email to python-dev-le...@python.org
https://mail.python.org/mailman3/lists/python-dev.python.org/
Message archived at 
https://mail.python.org/archives/list/python-dev@python.org/message/H4TOJPKULU2MQM436TJOF27MHUNFA2G2/

[Python-Dev] Re: fail keyword like there is pass keyword

[Jonathan Goble]

On Wed, Oct 28, 2020 at 12:48 PM Emily Bowman 
wrote:

> On Wed, Oct 28, 2020 at 6:49 AM Jean Abou Samra 
> wrote:
>
>> where `impossible` raises AssertionError.
>>
>
> Reserving a common English word as a new keyword (whether fail or
> impossible) is the mother of all breaking changes. The syntactic sugar it
> provides is not only tiny, it's pretty much negative, since any message it
> could provide would be too generic to be of much use, versus raising your
> own relevant exception message.
>

Indeed, especially when you can write this once at the top of your module,
or in a utils module in a larger package:

def unreachable():
raise AssertionError

and then Jean's example can be spelled:

match args:
 case [Point2d(x, y)]:
 ...
 case ...:
 ...
 case ...:
 ...
 case ...:
 ...
 case _:
 unreachable()

Same benefit of a plain English word, identical behavior, very very tiny
downside of two parentheses and a two-line function definition, and zero
breakage or compatibility issues.
___
Python-Dev mailing list -- python-dev@python.org
To unsubscribe send an email to python-dev-le...@python.org
https://mail.python.org/mailman3/lists/python-dev.python.org/
Message archived at 
https://mail.python.org/archives/list/python-dev@python.org/message/YNUJL3BUA7Z2UNQ7ECITTYEKX6U7SUQA/
Code of Conduct: http://python.org/psf/codeofconduct/

[Python-Dev] python.org doc portal question/bug

[Jonathan Goble]

On https://www.python.org/doc/ I notice that on the right side, under the
heading "Porting from Python 2 to Python 3", there is one bullet point that
is not linked to anywhere and just sits as plain text: "Determine what
projects are blocking you from porting to Python 3". It seems like a weird
place to have a bullet point of plain text that's quite a bit more specific
than surrounding bullets.

Is this line of text supposed to be on a different page? Is it supposed to
be linked to another page that explains how to find which projects are
blocking you? If the answer to both is no, why is it sitting somewhere
where (to me, at least) it looks out of place, and what can be done to make
it less jarring and less confusing?
___
Python-Dev mailing list -- python-dev@python.org
To unsubscribe send an email to python-dev-le...@python.org
https://mail.python.org/mailman3/lists/python-dev.python.org/
Message archived at 
https://mail.python.org/archives/list/python-dev@python.org/message/7IUE5AJZNYZHEGL4VYOFUKUYUCU7APMI/
Code of Conduct: http://python.org/psf/codeofconduct/

[Python-Dev] Re: python.org doc portal question/bug

[Jonathan Goble]

On Thu, Dec 3, 2020 at 6:16 PM Guido van Rossum  wrote:

> If you want to get the attention of the people who maintain the website,
> please look at the bottom of any page on python.org and file an issue at
> the GitHub tracker linked there.
>

Done: https://github.com/python/pythondotorg/issues/1697 Thanks for the
pointer.
___
Python-Dev mailing list -- python-dev@python.org
To unsubscribe send an email to python-dev-le...@python.org
https://mail.python.org/mailman3/lists/python-dev.python.org/
Message archived at 
https://mail.python.org/archives/list/python-dev@python.org/message/Q6WHC5BAU3BB35UMQD4VLMA3JZ34T7Z4/
Code of Conduct: http://python.org/psf/codeofconduct/

[Python-Dev] Re: __init_subclass__ and metaclasses

[Jonathan Goble]

On Wed, Dec 30, 2020, 1:05 AM Guido van Rossum  wrote:

> I need to think about this more.
>
> Technically the class *is* created at the point `__init_subclass__` is
> called. What the metaclass does after that point is embellishment.
>
> Most metaclasses will have sufficient control for their needs because they
> can manipulate the contents of the namespace that's passed to type_new() --
> I understand that doesn't work for Enum because the instances have a
> reference to the class in them.
>
> I suspect the classes that you claim are "buggy" are fine in practice,
> even if you can construct a counterexample.
>
> All in all I just worry about the backward compatibility here: one could
> easily imagine a metaclass whose `__new__` relies on the effect of the
> `__init_subclass__` called by type_new(), and moving the call would break
> that. So it's probably 6 bugs fixed, half a dozen new bugs created. In such
> a case, the status quo should win.
>

I admit I don't know anything about the metaclass internals, but if
backward compatibility is an issue, couldn't we create a new dunder instead
of moving the existing one? Say, call it __init_subclass_2__ (and bikeshed
the name later), and document that as being called at the point to which
it's currently proposed to move the calling of __init_subclass__.

With that, there is zero breakage of existing code, and code that can
benefit from the new behavior simply uses a different dunder.
__init_subclass__ could potentially be deprecated in the future if it's
determined that it has no benefit over the new dunder, but doesn't need to
deprecated immediately.

>
___
Python-Dev mailing list -- python-dev@python.org
To unsubscribe send an email to python-dev-le...@python.org
https://mail.python.org/mailman3/lists/python-dev.python.org/
Message archived at 
https://mail.python.org/archives/list/python-dev@python.org/message/VWNYDERWSPE7MIN2TVRSFM6AM7RLF6AO/
Code of Conduct: http://python.org/psf/codeofconduct/

[Python-Dev] Re: PEP 597: Add optional EncodingWarning

[Jonathan Goble]

On Tue, Feb 9, 2021 at 11:29 PM Terry Reedy  wrote:
>
> On 2/9/2021 8:28 PM, Inada Naoki wrote:
>
> > Note that many Python users don't use consoles.
>
> Those of use who do may find it hard to imagine just how easy we have
> made computing.
>
> My daughter minored in Computer Science about 6 years ago.  She never
> saw Command Prompt until the summer after her Junior year when she
> watched me use it to install numpy and other packages for her.  I had to
> do it because 'Run pip install numpy', etc, was met with a blank stare.
>   I had taught her Python with IDLE, downloaded and install with a
> browser, and had neglected to teach her 'Dos' until then.
>
> So had her CS classes.  Those previous used Racket in a Dr. something
> environment and Java in, I believe, Eclipse.  Also downloaded and
> installed with a browser.

Speaking as a current CS undergraduate student here (senior graduating
in December 2021). At my university, the freshman/sophomore-level
programming classes do not assume or expect any type of command line
knowledge. They all rely on GUI tools (Eclipse, IntelliJ, or NetBeans
for the freshman Java courses, Visual Studio for Data Structures in
C++).

There is one course, typically taken in either the second or third
semester for traditional students, called Operating Systems Concepts
and Usage, that broadly discusses how operating systems function, but
is also designed as a first introduction to Linux and to the command
line. (Until this point, the only operating system students are
assumed to be familiar with is Windows.) For many students, this
course is their first ever exposure to the command prompt.

After that, students in this program don't generally *need* to touch
the command line again in their studies until they hit 4000-level
courses, and even then only a few courses require it. Outside of that
one introductory course, I've only had two courses so far that
actually required command line usage. Everything else so far has
offered GUI options, even many upper level courses.

I think it's a disservice to fail to expose students to the command
line more and earlier, but the fact is, that failure happens and
happens often, and developers need to be conscious of that.

Despite my own ease and comfort with the command-line (which dates
back to learning my way around DOS at the age of 5) to the point of
almost always having a terminal window open on my daily Debian
machine, I frequently find myself opting for point-and-click solutions
to common problems, even Git operations (which are so easy and
powerful in VS Code with the GitLens extension). GUI tools grow more
powerful by the day, and it's very easy to get deep into a computer
science program these days and not be comfortable with the command
line and/or not know how to change environment variables.

Python, as a common introductory language used by many thousands of
people who have never taken a university computer course, never mind
majoring in computer science, shouldn't have basic features that
depend on the likely false assumption that the user has ever seen a
command prompt or an environment variable, much less comprehend how to
use them.
___
Python-Dev mailing list -- python-dev@python.org
To unsubscribe send an email to python-dev-le...@python.org
https://mail.python.org/mailman3/lists/python-dev.python.org/
Message archived at 
https://mail.python.org/archives/list/python-dev@python.org/message/UKGADFE6OK66BNUPE36NVHXBZZSOR7OD/
Code of Conduct: http://python.org/psf/codeofconduct/

[Python-Dev] Re: Python 0.9.1

[Jonathan Goble]

On Tue, Feb 16, 2021 at 5:02 PM Skip Montanaro  wrot
> A note to webmas...@python.org from an astute user named Hiromi in Japan* 
> referred us to Guido's shell archives for the 0.9.1 release from 1991.

Very interesting discovery! In my efforts to uncover the original
plaintext usenet post, I stumbled across this 12-year-old diary/blog
post: 
http://www.dalkescientific.com/writings/diary/archive/2009/03/27/python_0_9_1p1.html

A little further digging led to
https://www.python.org/download/releases/early/ which references the
above post and is the first hit on Google for the search query
"alt.sources python 0.9.1" (without the quotes).

> As that wasn't listed in the historical releases README file

It would be good to add it to that.
___
Python-Dev mailing list -- python-dev@python.org
To unsubscribe send an email to python-dev-le...@python.org
https://mail.python.org/mailman3/lists/python-dev.python.org/
Message archived at 
https://mail.python.org/archives/list/python-dev@python.org/message/Z22BR75Z4XZEWWM4V4DCO3Q6R6OMJDX5/
Code of Conduct: http://python.org/psf/codeofconduct/

[Python-Dev] Re: Have virtual environments led to neglect of the actual environment?

[Jonathan Goble]

On Tue, Feb 23, 2021 at 7:48 PM Random832  wrote:
>
> I was reading a discussion thread 
>  about 
> various issues with the Debian packaged version of Python, and the following 
> statement stood out for me as shocking:
>
> Christian Heimes wrote:
> > Core dev and PyPA has spent a lot of effort in promoting venv because we 
> > don't want users to break their operating system with sudo pip install.
>
> [snip]
>
> How is it that virtual environments have become so indispensable, that no-one 
> considers installing libraries centrally to be a viable model anymore? Are 
> library maintainers making breaking changes too frequently, reasoning that if 
> someone needs the old version they can just venv it? Is there some other 
> cause?

I can't speak for distributors or maintainers [1], but I can speak for
myself as a user. I run Debian testing (currently bullseye as that is
preparing for release) as my daily OS on my personal laptop, used for
personal matters and school assignments (I'm a university computer
science student in my senior year).

I don't use the system Python for anything of my own, whether it's a
school assignment or a personal project, precisely because I don't
want to risk screwing something up. Rather, I maintain a clone/fork of
the official CPython GitHub repo, and periodically build from source
and `make altinstall` into `~/.local/`. The `python3` command
continues to refer to the system Python, while `python3.8`, etc. refer
to the ones installed in my home folder. To the latter I make symlinks
for `py38`, `py39`, etc., and just `py` (and `pip`) for the one I use
most often (usually the latest stable release). I typically have
multiple versions installed at once since different scripts/projects
run on different versions at different times. Given this setup, I can
just do a simple `pip install spam` command and I don't need either
`sudo` or `--user`, nor do I need virtual envs.

While the average person would probably not clone the GitHub repo and
build that way, it's not terribly unreasonable for an inclined person
to do the same with a tarball downloaded from python.org, and so I
doubt I'm the only one with this type of setup.

Just some food for thought.

[1] Technically I am a library maintainer since I have a couple
projects on PyPI, but those are mostly unused and more or less
abandoned at this point, and neither ever reached the point where I
could consider graduating them from beta status. Most of what I work
with these days is private personal code or school assignments.
___
Python-Dev mailing list -- python-dev@python.org
To unsubscribe send an email to python-dev-le...@python.org
https://mail.python.org/mailman3/lists/python-dev.python.org/
Message archived at 
https://mail.python.org/archives/list/python-dev@python.org/message/M6OGQXKLG27Y6KA5L5UFBWA2NAZNBOHL/
Code of Conduct: http://python.org/psf/codeofconduct/

[Python-Dev] Re: stdlib Flag Enums and the "no value" member

[Jonathan Goble]

On Thu, Apr 29, 2021 at 1:20 PM Ethan Furman  wrote:

> 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 we want to have a standard name for stdlib
> Flags when no flags are set?
>
> What should we call it?
>
> - NONE
>
> - ZERO
>
> - EMPTY
>
> - ???
>

If you want a flag to represent no flags set, it takes one line to write it
yourself, as in this example I copied verbatim from the docs:

>>> class Color(Flag):
... BLACK = 0
... RED = auto()
... BLUE = auto()
... GREEN = auto()
...
>>> Color.BLACK

>>> bool(Color.BLACK)
False
___
Python-Dev mailing list -- python-dev@python.org
To unsubscribe send an email to python-dev-le...@python.org
https://mail.python.org/mailman3/lists/python-dev.python.org/
Message archived at 
https://mail.python.org/archives/list/python-dev@python.org/message/UXRKQQWM5HY6ECBBAQ2RUK2TNRJ2AQTT/
Code of Conduct: http://python.org/psf/codeofconduct/

[Python-Dev] Re: stdlib Flag Enums and the "no value" member

[Jonathan Goble]

On Thu, Apr 29, 2021 at 2:00 PM Ethan Furman  wrote:

> 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
> write it yourself, as in this example I copied
>  > verbatim from the docs:
>  >
>  >  >>> class Color(Flag):
>  > ... BLACK = 0
>  > ... RED = auto()
>  > ... BLUE = auto()
>  > ... GREEN = auto()
>  > ...
>  >  >>> Color.BLACK
>  > 
>  >  >>> bool(Color.BLACK)
>  > False
>
> Are you suggesting that the standard name for 0 be 'BLACK'?  ;-)
>

Any color you want as long as it's BLACK. ;-)

But seriously, my point is that it's already trivially possible for enum
authors to give the zero case a name of their own choosing that makes sense
for their use case, so we don't need special automatic names for it. The
one obvious way to do it, and the explicit way to do it, is to define your
own name to be equal to zero. Creating an automatic name for zero now,
after the enum module is well-established, violates the Zen of Python in at
least three, possibly four ways:

- it's implicit behavior (compared to the explicitness of defining your own
name)
- it violates the "one obvious way to do it" principle (I can conceivably
see arguments developing in the community over whether the automatic name
should be preferred or if one should write an explicit name for zero, as
neither is clearly and obviously better than the other)
- it requires a special case for backward compatibility with the
@enum.unique decorator
- it's arguably ambiguous what object should be returned for foo(0) when an
explicit name is defined (due to the documented behavior that a second name
for the same value is an alias for the first; is the automatic name created
first or last?)

So I don't see any compelling argument for giving an automatic name for
zero. Just define your own name. It takes five seconds and one line, with
essentially zero cost to maintainability.
___
Python-Dev mailing list -- python-dev@python.org
To unsubscribe send an email to python-dev-le...@python.org
https://mail.python.org/mailman3/lists/python-dev.python.org/
Message archived at 
https://mail.python.org/archives/list/python-dev@python.org/message/T3CHW4BTC4K7B5SGZUEFV5JSNCLO3YND/
Code of Conduct: http://python.org/psf/codeofconduct/

[Python-Dev] Re: [python-committers] [Release manager team communication] master blocked until 3.10 beta 1 is released

[Jonathan Goble]

On Mon, May 3, 2021 at 5:13 PM Victor Stinner  wrote:

> Hi,
>
> Please don't attempt to merge PRs until the GitHub issue described
> below is solved ;-)
>
> Pablo renamed the default "master" branch to "main" (in a live Twitch
> stream ;-)) but got a GitHub internal error! Maybe it's because the
> dialog announced that 1.4k+ pull requests and 700+ repositositories
> will be impacted which is not a common case. Right now, there are
> "main" and "master" branches.
>
> I reported the issue to GitHub Support forum:
>
> https://github.community/t/renaming-python-master-branch-to-main-1-4k-prs-700-repositories-triggered-server-http-error-500/178090
>
> Victor
>

To copy my reply from there:

Looks like it just needed time to process.
https://github.com/python/cpython/branches now shows “main” as the default
and no sign of a “master” branch. I checked one random PR and it now
targets “main”.
___
Python-Dev mailing list -- python-dev@python.org
To unsubscribe send an email to python-dev-le...@python.org
https://mail.python.org/mailman3/lists/python-dev.python.org/
Message archived at 
https://mail.python.org/archives/list/python-dev@python.org/message/BNR5ZDNUQFOGCXQVGLN5U23QVRXMSSHW/
Code of Conduct: http://python.org/psf/codeofconduct/

[Python-Dev] Re: github and dependabot

[Jonathan Goble]

On Mon, May 3, 2021 at 9:15 PM Łukasz Langa  wrote:

> It's bogus automation, you can safely reject those pull requests. If you
> do merge any pull requests to `main` of your personal fork, your `main`
> branch will diverge from python/cpython's. Not recommended.
>
> I just merged the equivalent pull requests from dependabot on
> python/cpython. You can pull from upstream.
>
> - Ł
>
> > On 4 May 2021, at 02:59, Ethan Furman  wrote:
> >
> > I have two pull requests against my cpython fork from a dependabot --
> what is that, and should I merge them?
> >
> > --
> > ~Ethan~
>

This is a known issue on GitHub's end, specifically that disabling
Dependabot on a fork is broken:
https://github.com/dependabot/dependabot-core/issues/2804 (note that a
comment specifically about the impact on CPython exists there as well).

The only workaround at the moment is to delete and recreate your fork,
after which Dependabot should be disabled so long as you never touch the
setting again.
___
Python-Dev mailing list -- python-dev@python.org
To unsubscribe send an email to python-dev-le...@python.org
https://mail.python.org/mailman3/lists/python-dev.python.org/
Message archived at 
https://mail.python.org/archives/list/python-dev@python.org/message/P473NI2MIY6O3N6E6RR66ED5SXZLHSUP/
Code of Conduct: http://python.org/psf/codeofconduct/

[Python-Dev] Re: Anyone else gotten bizarre personal replies to mailing list posts?

[Jonathan Goble]

I just got one now from the same person on the dependabot thread. Entirely
in Chinese except for "GNU license" in the middle, along with an attached
jpeg of a random SciPy-related tweet (according to Gmail's preview
thumbnail; I didn't actually open the attachment for obvious reasons).

On Sun, May 2, 2021, 5:08 AM Jeff Allen  wrote:

> Yes, I got one from the same address today. Thanks for pointing out these
> are individual peformances: it was annoying when I thought it was spam to
> the list.
>
> Although Hoi Lam Poon is a real (female) name, it may signify a generated
> lampoon.
>
> Jeff Allen
>
> On 23/04/2021 16:38, Nathaniel Smith wrote:
>
> I just got the reply below sent directly to my personal account, and I'm
> confused about what's going on. If it's just a one off I'll chalk it up to
> random internet weirdness, but if other folks are getting these too it
> might be something the list admins should look into? Or... something?
>
> -- Forwarded message -
> From: Hoi lam Poon 
>
> ___
> Python-Dev mailing list -- python-dev@python.org
> To unsubscribe send an email to python-dev-le...@python.org
> https://mail.python.org/mailman3/lists/python-dev.python.org/
> Message archived at
> https://mail.python.org/archives/list/python-dev@python.org/message/3EA53I3Y72ACEPDVG467NMNTXHRL3NXL/
> Code of Conduct: http://python.org/psf/codeofconduct/
>
___
Python-Dev mailing list -- python-dev@python.org
To unsubscribe send an email to python-dev-le...@python.org
https://mail.python.org/mailman3/lists/python-dev.python.org/
Message archived at 
https://mail.python.org/archives/list/python-dev@python.org/message/JNYRFZ4FTIFUJFS7FPNMKI2HXW7SLL52/
Code of Conduct: http://python.org/psf/codeofconduct/

[Python-Dev] Re: Future PEP: Include Fine Grained Error Locations in Tracebacks

[Jonathan Goble]

On Sat, May 8, 2021 at 5:08 PM Pablo Galindo Salgado 
wrote:

> > Why not put in it -O instead?  Then -O means lose asserts and lose
> fine-grained tracebacks, while -OO continues to also
> strip out doc strings.
>
> What if someone wants to keep asserts but do not want the extra data?
>

What if I want to keep asserts and docstrings but don't want the extra data?

Or actually, consider this. I *need* to keep asserts (because rightly or
wrongly, I have a dependency, or my own code, that relies on them), but I
*don't* want docstrings (because they're huge and I don't want the overhead
in production), and I *don't* want the extra data in production either.

Now what?

I think what this illustrates is that the entire concept of optimizations
in Python needs a complete rethink. It's already fundamentally broken for
someone who wants to keep asserts but remove docstrings. Adding a third
layer to this is a perfect opportunity to reconsider the whole paradigm.

I'm getting off-topic here, and this should probably be a thread of its
own, but perhaps what we should introduce is a compiler directive, similar
to future statements but not that, that one can place at the top of a
source file to tell the compiler "this file depends on asserts, don't
optimize them out". Same for each thing that can be optimized that has a
runtime behavior effect, including docstrings. This would be minimally
disruptive since we can then stay at only two optimization levels and put
column info at whichever level we feel makes sense, but (provided the
compiler directives are used properly) information a particular file
requires to function correctly will never be removed from that file even if
the process-wide optimization level calls for it. I see no reason code with
asserts in one file and optimized code without asserts in another file
can't interact, and no reason code with docstrings and optimized code
without docstrings can't interact. Soft keywords would make this compiler
directive much easier, as it doesn't have to be shoehorned into the import
syntax (to suggest a bikeshed color, perhaps "retain asserts, docstrings"?)
___
Python-Dev mailing list -- python-dev@python.org
To unsubscribe send an email to python-dev-le...@python.org
https://mail.python.org/mailman3/lists/python-dev.python.org/
Message archived at 
https://mail.python.org/archives/list/python-dev@python.org/message/QV7LVUKWC72XA23NBZMFA573V7HPU72Y/
Code of Conduct: http://python.org/psf/codeofconduct/

[Python-Dev] Re: name for new Enum decorator

[Jonathan Goble]

On Thu, May 27, 2021 at 11:34 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 appropriate... but
> I have no idea what to call it.
>
> Any nominations?
>

@prevent_missing_values?
@check_all_values_exist?
@sanity_check?

Just some midnight thoughts from me.
___
Python-Dev mailing list -- python-dev@python.org
To unsubscribe send an email to python-dev-le...@python.org
https://mail.python.org/mailman3/lists/python-dev.python.org/
Message archived at 
https://mail.python.org/archives/list/python-dev@python.org/message/YSZBK7ZDQ6MP3SPZY67HO34QOU3STHBQ/
Code of Conduct: http://python.org/psf/codeofconduct/

[Python-Dev] Re: python-dev thread w/ Marco Sulla

[Jonathan Goble]

On Mon, Aug 16, 2021 at 4:04 PM Nathan C. Fox 
wrote:

> Yes, it was intended to go to python-dev, even though it's not about
> Python development. It's part of a discussion about a pretty hostile and
> off-topic thread that has unfolded over the last week on this mailing list.
>

Brett's original post here reads as though it was intended as a private
email to a moderator, though.
___
Python-Dev mailing list -- python-dev@python.org
To unsubscribe send an email to python-dev-le...@python.org
https://mail.python.org/mailman3/lists/python-dev.python.org/
Message archived at 
https://mail.python.org/archives/list/python-dev@python.org/message/J6KOYHBSK4V2CV2LKRAP62467IERKY42/
Code of Conduct: http://python.org/psf/codeofconduct/

[Python-Dev] Re: Dropping out of this list

[Jonathan Goble]

On Wed, Aug 18, 2021 at 8:06 PM Luciano Ramalho  wrote:

> I bet I am not alone.
>
> Instead of going silently, I wanted to call on the adult supervision
> to do something about the adult.
>

Please.

I am mostly a lurker, but I am also considering unsubscribing if someone
doesn't step in and stop the mess going on between Brett and Marco. It's
becoming annoying to see adults, with doctorates even, who don't know how
to behave in public. I've seen five-year-olds that behave better than what
I've seen on this list recently.
___
Python-Dev mailing list -- python-dev@python.org
To unsubscribe send an email to python-dev-le...@python.org
https://mail.python.org/mailman3/lists/python-dev.python.org/
Message archived at 
https://mail.python.org/archives/list/python-dev@python.org/message/6ZXVIQ4OMOXPSC6L2CP5X4HXQTHNNOSC/
Code of Conduct: http://python.org/psf/codeofconduct/

[Python-Dev] Re: Dropping out of this list

[Jonathan Goble]

On Wed, Aug 18, 2021 at 10:22 PM Terry Reedy  wrote:

> On 8/18/2021 9:37 PM, Edwin Zimmerman wrote:
> > On 8/18/21 9:18 PM, Jonathan Goble wrote:
> >> I am mostly a lurker, but I am also considering unsubscribing if
> someone doesn't step in and stop the mess
> >
> > +1
>
> Both the email and newsreader parts of Thunderbird have an option called
> Ignore Thread.  Do your readers have such?
>

I consume my email from a variety of disparate devices, including a Debian
laptop, a Windows desktop, a Chromebook, an Android phone, and various
university-managed computer labs. As such, and as I rely heavily on Gmail's
filtering and labeling system to manage my email, I rely solely on Google's
standard web interface and Android app for Gmail for the sake of a
consistent experience across devices. I don't know if Google offers such an
option. It takes me about three seconds to click a thread, see the arguing,
and click Archive, but I'm getting tired of doing that repeatedly.
___
Python-Dev mailing list -- python-dev@python.org
To unsubscribe send an email to python-dev-le...@python.org
https://mail.python.org/mailman3/lists/python-dev.python.org/
Message archived at 
https://mail.python.org/archives/list/python-dev@python.org/message/PTFMX4YD6QGFJOMWLEKHAEZKXULUQIGG/
Code of Conduct: http://python.org/psf/codeofconduct/

[Python-Dev] Re: PEP 654 except* formatting

[Jonathan Goble]

On Sun, Oct 3, 2021 at 11:40 PM Steven D'Aprano  wrote:

> On Sun, Oct 03, 2021 at 11:34:55AM -0700, Guido van Rossum wrote:
>
> > I also think that the bar should be pretty high before we reopen the
> > *syntax* -- the PEP was approved without anyone (neither the SC, nor
> > Nathaniel, nor anyone else) providing any feedback on the use of 'except
> > *'. So I think it's a bit late to be bikeshedding the syntax. This thread
> > was meant to solicit feedback on how to *format* it: does the space go
> > before or after the '*'.
>
> `except* E`, otherwise it looks like unpacking E.
>

I think it's worth noting that the following is already legal:

Python 3.9.7 (tags/v3.9.7:1016ef3, Aug 30 2021, 20:19:38) [MSC v.1929 64
bit (AMD64)] on win32
Type "help", "copyright", "credits" or "license" for more information.
>>> exceptions = (ValueError, TypeError)
>>> try:
...   raise TypeError
... except exceptions:
...   print("caught")
...
caught

Indeed, when I first learned that you could do this (a few years ago IIRC),
my first thought was to unpack the "exceptions" tuple with a star. It
wasn't until I tried that and got a SyntaxError that I tried it the way
shown here and it worked.

Allowing `except *E` for this new feature would take that
helpful-to-a-beginner SyntaxError and turn it into a subtle and unhelpful
bug.

Therefore my vote is for requiring `except* E` and keeping `except *E` as a
SyntaxError.
___
Python-Dev mailing list -- python-dev@python.org
To unsubscribe send an email to python-dev-le...@python.org
https://mail.python.org/mailman3/lists/python-dev.python.org/
Message archived at 
https://mail.python.org/archives/list/python-dev@python.org/message/2TBZZSMZXNYFJNPLIESFNFDNDX5K6A5X/
Code of Conduct: http://python.org/psf/codeofconduct/

[Python-Dev] Re: PEP 654 except* formatting

[Jonathan Goble]

On Mon, Oct 4, 2021 at 1:24 AM Guido van Rossum  wrote:

> On Sun, Oct 3, 2021 at 9:20 PM Jonathan Goble  wrote:
>
>> Therefore my vote is for requiring `except* E` and keeping `except *E` as
>> a SyntaxError.
>>
>
> You can't do that with our current lexer+parser.
>

Then what is the purpose of this thread? I understood from the OP that the
question was which to allow and which to prohibit. If it's impossible to
require either or prohibit either because the lexer/parser can't tell the
difference, then it's going to end up as a never-ending style argument just
like C pointers, so what are we even discussing? (Other than an entirely
different syntax, of course, which now seems like the logical way to go if
we can't enforce a single way to do it with the original proposal.)
___
Python-Dev mailing list -- python-dev@python.org
To unsubscribe send an email to python-dev-le...@python.org
https://mail.python.org/mailman3/lists/python-dev.python.org/
Message archived at 
https://mail.python.org/archives/list/python-dev@python.org/message/QVAC5VMVPJLMQ7PAGTAKJXYYOYAZE7CZ/
Code of Conduct: http://python.org/psf/codeofconduct/

Re: [Python-Dev] Problem

[Jonathan Goble]

General questions like this belong on python-list, not python-dev.

To answer your question, though, you need to run that command from the
Windows Command Prompt, not from the Python interpreter.
___
Python-Dev mailing list
Python-Dev@python.org
https://mail.python.org/mailman/listinfo/python-dev
Unsubscribe: 
https://mail.python.org/mailman/options/python-dev/archive%40mail-archive.com

Re: [Python-Dev] PEP 467: next round

[Jonathan Goble]

*de-lurks*

On Mon, Jul 18, 2016 at 4:45 PM, Alexander Belopolsky
 wrote:
> On Mon, Jul 18, 2016 at 4:17 PM, Ethan Furman  wrote:
>>
>> - 'bytes.zeros' renamed to 'bytes.size', with option byte filler
>>   (defaults to b'\x00')
>
>
> Seriously?  You went from a numpy-friendly feature to something rather
> numpy-hostile.
> In numpy, ndarray.size is an attribute that returns the number of elements
> in the array.
>
> The constructor that creates an arbitrary repeated value also exists and is
> called numpy.full().
>
> Even ignoring numpy, bytes.size(count, value=b'\x00') is completely
> unintuitive.  If I see bytes.size(42) in someone's code, I will think:
> "something like int.bit_length(), but in bytes."

full(), despite its use in numpy, is also unintuitive to me (my first
thought is that it would indicate whether an object has room for more
entries).

Perhaps bytes.fillsize? That would seem the most intuitive to me:
"fill an object of this size with this byte". I'm unfamiliar with
numpy, but a quick Google search suggests that this would not conflict
with anything there, if that is a concern.

> This PEP isn't revisiting that original design decision, just changing the
> spelling as users sometimes find the current behaviour of the binary
> sequence
> constructors surprising. In particular, there's a reasonable case to be made
> that ``bytes(x)`` (where ``x`` is an integer) should behave like the
> ``bytes.byte(x)`` proposal in this PEP. Providing both behaviours as
> separate
> class methods avoids that ambiguity.

You have a leftover bytes.byte here.
___
Python-Dev mailing list
Python-Dev@python.org
https://mail.python.org/mailman/listinfo/python-dev
Unsubscribe: 
https://mail.python.org/mailman/options/python-dev/archive%40mail-archive.com

[Python-Dev] Where are the list and array.array implementations in CPython source?

[Jonathan Goble]

I'd like to study the CPython implementations of lists and array.array
instances for a personal project of mine, but I've very unfamiliar
with the Python source code as it pertains to internals like this.
Which files would I need to look at to do this, and are there a few
particular functions/structures I should pay attention to? I'm just
looking for a brief pointer in the right direction here, not a full
explanation of how it works -- I'll get that from studying the source
code. :-)

(Sorry if this isn't the best place to post, but I felt that a
question about CPython's internals fit slightly better on python-dev
rather than python-list, since this is where those familiar with that
code are more likely to see the post.)
___
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] Where are the list and array.array implementations in CPython source?

[Jonathan Goble]

On Mon, Sep 5, 2016 at 8:10 PM, Martin Panter  wrote:
> Built-in objects are usually in the Objects/ directory, with a
> corresponding include file in the Include/ directory:
> https://hg.python.org/cpython/file/default/Objects/listobject.c
> https://hg.python.org/cpython/file/default/Include/listobject.h
>
> Modules implemented in C are usually in the Modules/ directory:
> https://hg.python.org/cpython/file/default/Modules/arraymodule.c


On Mon, Sep 5, 2016 at 8:10 PM, Benjamin Peterson  wrote:
> Include/listobject.h
> Objects/listobject.c
> Modules/arraymodule.c


Thanks to both of you. I'll start looking at those soon. :)
___
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] Outdated GitHub clone of the old svn repository

[Jonathan Goble]

On Fri, May 5, 2017 at 12:33 PM Victor Stinner 
wrote:

> Is https://github.com/python-git a real user or an organization?
>

It appears to me to be an individual user rather than an organization.
___
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] Outdated GitHub clone of the old svn repository

[Jonathan Goble]

On Fri, May 5, 2017 at 12:52 PM Brett Cannon  wrote:

> On Fri, 5 May 2017 at 09:50 Victor Stinner 
> wrote:
>
>> 2017-05-05 18:36 GMT+02:00 Jonathan Goble :
>> > It appears to me to be an individual user rather than an organization.
>>
>> Oh nice, glad to meet you :-) So what do you think? Are you ok to
>> remove this old clone? Or do you have reasons to keep it?
>>
>
> I don't think Jonathan was claiming ownership of the python-git account,
> just pointed out the account is a personal account of somebody's and not an
> organization account.
>

Right. I was just answering the "user or organization?" question. I have
only one GItHub account, and that is not it.
___
Python-Dev mailing list
Python-Dev@python.org
https://mail.python.org/mailman/listinfo/python-dev
Unsubscribe: 
https://mail.python.org/mailman/options/python-dev/archive%40mail-archive.com

[Python-Dev] Re: PEP 467: Minor bytes and bytearray improvements

[Jonathan Goble]

On Thu, Nov 4, 2021 at 10:37 AM Eric Fahlgren 
wrote:

> On Thu, Nov 4, 2021 at 12:01 AM Ethan Furman  wrote:
>
>>  >>> bytearray.fromsize(5, fill=b'\x0a')
>>  bytearray(b'\x0a\x0a\x0a\x0a\x0a')
>>
>
> What happens if you supply more than one byte for the fill argument?
> Silent truncation, raise ValueError('too long') or ???
>

It would seem reasonable to me for a multi-byte sequence to be filled as-is
in a repeating pattern, perhaps truncating the last repetition if len(fill)
is not an even multiple of the size. At least that's the intuitive behavior
for me.

That said, I don't know if such behavior would be useful in practice (i.e.
whether there's a use case for it).
___
Python-Dev mailing list -- python-dev@python.org
To unsubscribe send an email to python-dev-le...@python.org
https://mail.python.org/mailman3/lists/python-dev.python.org/
Message archived at 
https://mail.python.org/archives/list/python-dev@python.org/message/I4OE6VPBOBYBUQD45PJJKNR4BHA5EQF6/
Code of Conduct: http://python.org/psf/codeofconduct/

[Python-Dev] Re: [OT] Re: Raw strings ending with a backslash

[Jonathan Goble]

Trying again after I was mysteriously moderated. Thanks Ethan for fixing
that.

On Sat, May 28, 2022 at 6:59 PM Jonathan Goble  wrote:

> On Sat, May 28, 2022, 4:25 PM Gregory P. Smith  wrote:
>
>>
>> On Sat, May 28, 2022 at 12:55 PM Guido van Rossum 
>> wrote:
>>
>>>
>>> On Sat, May 28, 2022 at 12:11 MRAB
>>>
>>> Names in Python are case-sensitive, yet the string prefixes are
>>>> case-/insensitive/.
>>>>
>>>> Why?
>>>
>>>
>>> IIRC we copied this from C for numeric suffixes  (0l and 0L are the
>>> same; also hex digits and presumably 0XA == 0xa) and then copied that for
>>> string prefixes without thinking about it much. I guess it’s too late to
>>> change.
>>>
>>
>> Given that 99.99% of code uses lower case string prefixes we *could*
>> change it, it'd just take a longer deprecation cycle - you'd probably want
>> a few releases where the upper case prefixes become an error in files
>> without a `from __future__ import case_sensitive_quote_prefixes` rather
>> than jumping straight from parse time DeprecationWarning to repurposing the
>> uppercase to have a new meaning.  The inertia behind doing that over the
>> course of 5+ years is high.  Implying that we'd need a compelling reason to
>> orchestrate it.  None has sprung up.
>>
>
> There already is a semantic meaning in one case, though not in Python
> proper. Some syntax highlighters, including the one used in VSCode, treat r
> and R differently: the former is syntax highlighted as a regex and the
> latter is syntax highlighted as an generic string. I have seen
> project-specific style guides advising to use r/R accordingly.
>
> So there is meaningful use of capital R in real-world code, and any future
> change to require lowercase would need to at least consider the impact on
> that use case.
>
>>
___
Python-Dev mailing list -- python-dev@python.org
To unsubscribe send an email to python-dev-le...@python.org
https://mail.python.org/mailman3/lists/python-dev.python.org/
Message archived at 
https://mail.python.org/archives/list/python-dev@python.org/message/OVYSKRJ2URA6AWV6QW7I77SVNR6ZNFOY/
Code of Conduct: http://python.org/psf/codeofconduct/

[Python-Dev] Re: Switching to Discourse

[Jonathan Goble]

On Thu, Jul 21, 2022, 15:26 Baptiste Carvello <
devel2...@baptiste-carvello.net> wrote:

> Le 21/07/2022 à 07:59, Stefan Behnel a écrit :
> >
> > I'm actually reading python-dev, c.l.py etc. through Gmane, and have
> > done that ever since I joined. Simply because it's a mailing list of
> > which I don't need a local (content) copy, and wouldn't want one. Gmane
> > seems to have a complete archive that's searchable, regardless of "when
> > I subscribed".
> >
> > It's really sad that Discourse lacks an NNTP interface. […]
>
> +1000
>
> For this switch to accommodate all use cases, Discourse really needs a
> "lurking" story.
>
> That's lacking right now, possibly by design (Discourse developers are
> quite opinionated*, and anonymous reading seemingly doesn't fit their
> worldview). Maybe they can be convinced, though…


Lurker here. :) I lurk, both on -ideas and -dev, primarily to stay
well-informed on new ideas coming down the pipeline, and occasionally (but
rarely) voice my two cents.

I signed up on Discourse after this thread started, and turned on mailing
list mode immediately. So far, I have no problems with that. It suits my
purpose just fine once I muted the Users forum. I might mute a few others
soon.

I consume the mailing lists (and now Discourse) through standard Gmail
interfaces (both the web interface and the official Android app), so I
cannot speak to the lack of proper threading (it's all linear anyway in
Gmail). I do use filters in Gmail to label threads by list, and I found
that Discourse plays nice with this: each forum, like each mailing list,
has its own mailing list attribute with a corresponding "list:" search
prefix in Gmail, so filtering, labeling, and organizing by forum is easy.
(Example: https://snipboard.io/WGF6Qz.jpg)
___
Python-Dev mailing list -- python-dev@python.org
To unsubscribe send an email to python-dev-le...@python.org
https://mail.python.org/mailman3/lists/python-dev.python.org/
Message archived at 
https://mail.python.org/archives/list/python-dev@python.org/message/JSK36LMJGHHDKTCJHF44HNIEXUZYQO5K/
Code of Conduct: http://python.org/psf/codeofconduct/

[Python-Dev] Re: Switching to Discourse

[Jonathan Goble]

On Thu, Jul 21, 2022 at 6:47 PM Steven Barker  wrote:

> On Mon, Jul 18, 2022 at 6:28 AM Petr Viktorin  wrote:
>
>> On 16. 07. 22 8:48, Miro Hrončok wrote:
>> > On 15. 07. 22 13:18, Petr Viktorin wrote:
>> >> - You can use discuss.python.org's “mailing list mode” (which
>> >> subscribes you to all new posts), possibly with filtering and/or
>> >> categorizing messages locally.
>>
> [...]
>
>> > What would be a good resource to read about this - where do I learn how
>> > to use discuss.python.org's in the “mailing list mode”
>>
>> Is this note enough?
>>
>> https://devguide.python.org/developer-workflow/communication-channels/?highlight=discourse#enabling-mailing-list-mode
>>
> [...]
>
> So last night I tried activating mailing list mode, and I'm not remotely
> satisfied with the experience so far. Where mailing lists are concerned,
> I'm *only *subscribed to python-dev. Not python-users, not -ideas, not
> -packaging (if that's still a thing). But Discourse's mailing list mode
> sends me messages for all of those things in such a volume that it drowns
> out any discussions on topics that would have shown up on python-dev (I
> think one PEP discussion message came in overnight, compared to 20+ posts
> on other tags). After the first two -users messages came in almost
> immediately, I tried telling discourse to mute the tags I don't care about,
> but it seems not to work at all. The page with the mailing list mode toggle
> warns that it overrides other email settings, so I think I just get
> everything regardless of other settings.
>
> If my only option is to be subscribed to a firehose of stuff I don't care
> about, I'm going to disable mailing list mode and if python-dev dies, I'll
> pretty much quit following Python's development. Now, I'm not a very
> important Python developer, I'm not a core dev, and my contributions are a
> few bug reports and a few patches over many years. But if there's no way to
> lurk on a modest-volume mailing list and contribute only occasionally,
> you're not going to get nearly as many people paying attention. I'm sure I
> could set up a whole suite of filters on my own end (e.g. discard any email
> with a subject starting with "[py] [Users]"), but that's an absurd and
> unnecessary burden, and it will only get worse the more categories you add
> to discourse (and I think the ease of adding categories is supposed to be a
> *feature*). This plan is going to drive developers like me away.
>
> For discourse mailing list mode to be a reasonable substitute for
> python-dev, it needs filtering on the sending end to work. Ideally there
> would be a way to subscribe only to the things I care about. Maybe that
> exists, but it's buried in menus I don't understand (or which mailing list
> mode overrides).
>

Mailing list mode indeed turns on the entire firehose, but you can
selectively turn things off (like the Users category). If you go to a
category page, click the bell icon in the upper right, and choose Muted,
you'll stop getting emails from that category, even in mailing list mode. I
muted the Users category almost immediately, which drastically slowed the
firehose. I'm now monitoring to decide what other categories are annoying
enough to mute, but the flow is slow enough when combined with my Gmail
filters to not need immediate action like the Users category did.
___
Python-Dev mailing list -- python-dev@python.org
To unsubscribe send an email to python-dev-le...@python.org
https://mail.python.org/mailman3/lists/python-dev.python.org/
Message archived at 
https://mail.python.org/archives/list/python-dev@python.org/message/Z2Y4UMNYLPYYYMBOZ3BZAJBANQNENS2L/
Code of Conduct: http://python.org/psf/codeofconduct/

[Python-Dev] Re: What to do about invalid escape sequences

[Jonathan Goble]

On Fri, Aug 9, 2019 at 12:34 PM Nick Coghlan  wrote:
>
> I find the "Our deprecation warnings were even less visible than
> normal" argument for extending the deprecation period compelling.

Outsider's 2 cents from reading this discussion (with no personal
experience with this warning):

I am perplexed at the opinion, seemingly espoused by multiple people
in this thread, that because a major part of the problem is that the
warnings were not visible enough, somehow the proposed solution is
making them not visible enough again? It's too late, in my
understanding, in the 3.8 cycle to add a new feature like a change to
how these warnings are produced (it seems a significant change to the
.pyc structure is needed to emit them at runtime), so this supposed
"solution" is nothing but kicking the can down the road. When 3.9
rolls around, public exposure to the problem of invalid escape
sequences will still be approximately what it is now (because if
nobody saw the warnings in 3.7, they certainly won't see them in 3.8
with this "fix"), so you'll end up with the same complaints about
SyntaxWarning that started this discussion, end up back on
DeprecationWarning for 3.9 (hopefully with support for emitting them
at runtime instead of just compile-time), then have to wait until
3.10/4.0 for SyntaxWarning and eventually the next version to actually
make them errors.

It seems to me, in my humble but uneducated opinion, that if people
are not seeing the warnings, then continuing to give them warnings
they won't see isn't a solution to anything. Put the warning front and
center. The argument of third-party packages will always be an issue,
even if we wait ten years. So put these warnings front and center now
so package and code maintainers actually see it, and I'll bet the
problematic escape sequences get fixed rather quickly.

What am I missing here?
___
Python-Dev mailing list -- python-dev@python.org
To unsubscribe send an email to python-dev-le...@python.org
https://mail.python.org/mailman3/lists/python-dev.python.org/
Message archived at 
https://mail.python.org/archives/list/python-dev@python.org/message/6ZBX2PULRGIRUBQ735ONGV2RZU2LP3WQ/

[Python-Dev] Re: What to do about invalid escape sequences

[Jonathan Goble]

On Fri, Aug 9, 2019 at 2:36 PM Eric V. Smith  wrote:
>
> On 8/9/2019 2:28 PM, Jonathan Goble wrote:
> > On Fri, Aug 9, 2019 at 12:34 PM Nick Coghlan  wrote:
> >> I find the "Our deprecation warnings were even less visible than
> >> normal" argument for extending the deprecation period compelling.
> > Outsider's 2 cents from reading this discussion (with no personal
> > experience with this warning):
> >
> > I am perplexed at the opinion, seemingly espoused by multiple people
> > in this thread, that because a major part of the problem is that the
> > warnings were not visible enough, somehow the proposed solution is
> > making them not visible enough again? It's too late, in my
> > understanding, in the 3.8 cycle to add a new feature like a change to
> > how these warnings are produced (it seems a significant change to the
> > .pyc structure is needed to emit them at runtime), so this supposed
> > "solution" is nothing but kicking the can down the road. When 3.9
> > rolls around, public exposure to the problem of invalid escape
> > sequences will still be approximately what it is now (because if
> > nobody saw the warnings in 3.7, they certainly won't see them in 3.8
> > with this "fix"), so you'll end up with the same complaints about
> > SyntaxWarning that started this discussion, end up back on
> > DeprecationWarning for 3.9 (hopefully with support for emitting them
> > at runtime instead of just compile-time), then have to wait until
> > 3.10/4.0 for SyntaxWarning and eventually the next version to actually
> > make them errors.
>
> Yes, I think that's the idea: Deprecation warning in 3.9, but more
> visible that what 3.7 has. That is, not just at compile time but at run
> time. What's required to make that happen is an open question.
>
> > It seems to me, in my humble but uneducated opinion, that if people
> > are not seeing the warnings, then continuing to give them warnings
> > they won't see isn't a solution to anything. Put the warning front and
> > center. The argument of third-party packages will always be an issue,
> > even if we wait ten years. So put these warnings front and center now
> > so package and code maintainers actually see it, and I'll bet the
> > problematic escape sequences get fixed rather quickly.
> >
> > What am I missing here?
>
> Hopefully the warnings in 3.9 would be more visible that what we saw in
> 3.7, so that library authors can take notice and do something about it
> before 3.10 rolls around.

OK, so I'm at least understanding the plan correctly. I just don't get
the idea of kicking the can down the road on the hope that in 3.9
people will see the warning (knowing that you are still using a
warning that is disabled by default and thus has a high chance of not
being seen until 3.10), when we already have the ability to push out a
visible-by-default warning now in 3.8 and get people to take notice
two whole feature releases (= about 3 years) earlier.

The SyntaxWarning disruption (or SyntaxError disruption) has to happen
eventually, and while I support the idea of making compile-time
DeprecationWarnings be emitted at runtime, I really don't think that a
disabled-by-default warning is going to change a whole lot. Sure, the
major packages will likely see it and update their code, but lots of
smaller specialty packages and independent developers won't see it in
3.9. The bulk of the change isn't going to happen until we go to
SyntaxWarning, so why not just get it over with instead of dragging it
out for three years?
___
Python-Dev mailing list -- python-dev@python.org
To unsubscribe send an email to python-dev-le...@python.org
https://mail.python.org/mailman3/lists/python-dev.python.org/
Message archived at 
https://mail.python.org/archives/list/python-dev@python.org/message/CWM2KO5IA24UCBSAYJP735EYKXIRRQRG/

[Python-Dev] Re: PEP 601: discussion-to discuss.python.org

[Jonathan Goble]

On Sat, Sep 7, 2019, 8:59 AM Rob Cliffe via Python-Dev <
python-dev@python.org> wrote:

>
> I can't make sense of this sentence in the PEP, I suspect there is a
> typo in it:
>
> "Since this is the removal of a feature teaching users will be one by
> the raising of a SyntaxError if/when the forbidden feature is used."
>
> Rob Cliffe
>

Without context, I would guess that "one" is a typo for "done", which would
make much more sense in that spot in the sentence. A comma after the first
"feature" would also help in parsing the sentence.

>
___
Python-Dev mailing list -- python-dev@python.org
To unsubscribe send an email to python-dev-le...@python.org
https://mail.python.org/mailman3/lists/python-dev.python.org/
Message archived at 
https://mail.python.org/archives/list/python-dev@python.org/message/I3KSYGOCNFBXL2P7H2DQDPISZDZZGRXI/

[Python-Dev] Re: Helpers for dynamic bytecode generation

[Jonathan Goble]

On Thu, Oct 24, 2019, 9:05 PM Yonatan Zunger  wrote:

> Hi everyone,
>
> Has anyone already done this that people know of? (Searching the
> Internetz didn't turn anything up) Failing that, to what extent is it
> reasonable to either consider assemble() as some kind of sane API point
> into compile.c, and/or add some new API in compile.h which implements all
> of the stuff described above in C?
>
> (I'm fully expecting the answer to these latter questions to be "you have
> got to be kidding me," but figured it was wiser to check than to reinvent
> this particular wheel if it isn't necessary)
>

There is byteplay (https://github.com/tallforasmurf/byteplay), but it is
broken on Python 3.6+ due to the change to wordcode. There is also a newer
one called simply "bytecode" (https://github.com/vstinner/bytecode) that
appears to work through at least 3.7 (though I haven't personally tried it.

>
___
Python-Dev mailing list -- python-dev@python.org
To unsubscribe send an email to python-dev-le...@python.org
https://mail.python.org/mailman3/lists/python-dev.python.org/
Message archived at 
https://mail.python.org/archives/list/python-dev@python.org/message/L7UWUOI22RNKJUUXDB6FV4XXBH3HP4QT/
Code of Conduct: http://python.org/psf/codeofconduct/

[Python-Dev] Re: Review status policy [was: PEP 585: Type Hinting Generics ...]

[Jonathan Goble]

On Sat, Mar 14, 2020 at 11:55 AM Guido van Rossum  wrote:

> Maybe this can be done by using the public SC issue tracker:
> https://mail.google.com/mail/u/0/#inbox/FMfcgxwHMPfZfZKJSsbVCFPXmLBQlHQd
>

That looks like a private Gmail link, possibly a copy-and-paste mixup. Can
you give the correct link?
___
Python-Dev mailing list -- python-dev@python.org
To unsubscribe send an email to python-dev-le...@python.org
https://mail.python.org/mailman3/lists/python-dev.python.org/
Message archived at 
https://mail.python.org/archives/list/python-dev@python.org/message/QZH4EK7OAHEPLLH4MMB2HSBY5TU3XL6F/
Code of Conduct: http://python.org/psf/codeofconduct/

[Python-Dev] Question about bytecode stability

[Jonathan Goble]

I'm getting ready to get back into an old personal project with some new
ideas. Before I do, I need to ask a question regarding the stability of
CPython bytecode. Before you say it, I am well aware and fully understand
that the opcodes may change in value and semantics between 3.x and 3.(x+1)
without notice, and that's acceptable to me.

My question is, are the opcodes guaranteed stable across the lifetime of a
single 3.x release? In other words, are they guaranteed to not change
values or semantics between 3.x.y and 3.x.(y+1)? Reading through the list
of opcodes in the dis documentation, it seems that all changes have
occurred in 3.x.0, so it seems the answer would be yes, but then the
"CPython implementation detail" paragraph at the top doesn't specify that
and is a little vague on whether that's true or not.

(For context, my personal project is a BASIC implementation in Python that
would compile to Python bytecode.)
___
Python-Dev mailing list -- python-dev@python.org
To unsubscribe send an email to python-dev-le...@python.org
https://mail.python.org/mailman3/lists/python-dev.python.org/
Message archived at 
https://mail.python.org/archives/list/python-dev@python.org/message/Z6RRM4WQAKBKMLPBCOMB47NDPEROVTTZ/
Code of Conduct: http://python.org/psf/codeofconduct/

[Python-Dev] Re: Question about bytecode stability

[Jonathan Goble]

On Mon, Apr 6, 2020 at 12:02 AM Chris Angelico  wrote:

> On Mon, Apr 6, 2020 at 1:53 PM Jonathan Goble  wrote:
> >
> > I'm getting ready to get back into an old personal project with some new
> ideas. Before I do, I need to ask a question regarding the stability of
> CPython bytecode. Before you say it, I am well aware and fully understand
> that the opcodes may change in value and semantics between 3.x and 3.(x+1)
> without notice, and that's acceptable to me.
> >
> > My question is, are the opcodes guaranteed stable across the lifetime of
> a single 3.x release? In other words, are they guaranteed to not change
> values or semantics between 3.x.y and 3.x.(y+1)? Reading through the list
> of opcodes in the dis documentation, it seems that all changes have
> occurred in 3.x.0, so it seems the answer would be yes, but then the
> "CPython implementation detail" paragraph at the top doesn't specify that
> and is a little vague on whether that's true or not.
> >
>
> The best way to look at this is to consider how long a .pyc file is
> valid. They're currently named something like
> __pycache__/modulename.cpython-38.pyc which is a fairly clear
> indication that the cached compiled module should be valid for any
> CPython 3.8.x release. So yes, you should be safe within any given
> release. The reason it's a CPython implementation detail is also
> hinted at in the file name: if you were to use Jython or PyPy or
> IronPython or MicroPython or any other implementation, you can't be
> sure your bytecodes will work, even if the version number is the same.
> (An interpreter can be compatible with Python 3.8 without having the
> same bytecode as CPython 3.8.)
>
> So for your purposes, it sounds like, yes, this WILL work. :)
>
> ChrisA
>

Thanks, I never really looked closely at .pyc files, so I missed that. Good
to know that I only have to watch for changes between feature releases.

I knew that about "CPython implementation detail", that it wouldn't be
valid on non-CPython implementations, but didn't clearly state so in the
OP. Regardless, I appreciate the reminder.
___
Python-Dev mailing list -- python-dev@python.org
To unsubscribe send an email to python-dev-le...@python.org
https://mail.python.org/mailman3/lists/python-dev.python.org/
Message archived at 
https://mail.python.org/archives/list/python-dev@python.org/message/O6MPYVBVDXDV3SNAYNNGVGQHDTMNHAQM/
Code of Conduct: http://python.org/psf/codeofconduct/

[Python-Dev] Re: Question about bytecode stability

[Jonathan Goble]

 Thanks for the feedback, everyone. I'm satisfied that the bytecodes are
stable enough to work for my purpose. Now I just have to find time to work
on it around my schoolwork.
___
Python-Dev mailing list -- python-dev@python.org
To unsubscribe send an email to python-dev-le...@python.org
https://mail.python.org/mailman3/lists/python-dev.python.org/
Message archived at 
https://mail.python.org/archives/list/python-dev@python.org/message/QEC773MKZI2YWMKN75PUA3PKR2I6EPPU/
Code of Conduct: http://python.org/psf/codeofconduct/

[Python-Dev] Re: REPL output bug

[Jonathan Goble]

On Mon, Jun 15, 2020 at 8:31 PM Steven D'Aprano  wrote:

> On Fri, Jun 12, 2020 at 09:01:33AM +0100, Rob Cliffe via Python-Dev wrote:
> > It appears that the requested characters are output, *followed by* the
> > number of characters output
> > (which is the value returned by sys.stdout.write) and a newline.
> > Surely this is not the intended behaviour.
>
> Of course it is. The whole point of the REPL is to evaluate an
> expression and have the result printed. (That's the P in REPL :-)
>
> `stdout.write(...)` is an expression that returns a value, so the REPL
> prints it.
>

The expected behavior, at least for me until I read this thread, was that
the REPL would print the result of a *bare* expression, meaning when the
complete statement entered is an expression when taken as a whole.

In other words, I would expect the following input and output in Python 3:

>>> sys.stdout.write('\r1')
12
>>> for i in range(1, 11):
...sys.stdout.write('\r%d' % i)
...time.sleep(1)
10>>>

because the first statement is, as a whole, a single expression and thus
should print its result, but a for statement and block is not a single
expression taken as a whole and therefore should not print intermediate (or
final) results.
___
Python-Dev mailing list -- python-dev@python.org
To unsubscribe send an email to python-dev-le...@python.org
https://mail.python.org/mailman3/lists/python-dev.python.org/
Message archived at 
https://mail.python.org/archives/list/python-dev@python.org/message/YMVL7RMQTYA7JIGTUQI6ZNS3MAHZRVK6/
Code of Conduct: http://python.org/psf/codeofconduct/

[Python-Dev] Re: Re Re: Recent PEP-8 change (Ivan Pozdeev)

[Jonathan Goble]

On Thu, Jul 2, 2020 at 7:55 PM Eric V. Smith  wrote:

> But this commit was to the peps repo, which has far fewer commits, one
> branch, no tags, and only 10 PRs. So while it's still an issue, it's not as
> big a deal as if we were talking about the cpython repo.
>
> I don't know how many forks have been made since the commit in question.
>
I don't know about new forks that are just sitting there, but GitHub has a
handy network graph that shows where every fork has diverged from the main
repo: https://github.com/python/peps/network

If you look to the right of the line down to KeanaBerlin on June 26, it
seems that six people have pushed commits to a fork that diverged after
that commit (plus one that committed something to an old fork). That is
based on the time of the commit to the fork, not when it was merged into
the main repo, so it could be fewer, but in any case no more than six
people would need to force-push to their fork(s) if a rewrite was done now.
Also, some of those forks may have already been the subject of PRs that
have been merged, and therefore may be able to be ignored.
___
Python-Dev mailing list -- python-dev@python.org
To unsubscribe send an email to python-dev-le...@python.org
https://mail.python.org/mailman3/lists/python-dev.python.org/
Message archived at 
https://mail.python.org/archives/list/python-dev@python.org/message/64LIUO4C3EWT45YCTRZLDA7B7IE33IXA/
Code of Conduct: http://python.org/psf/codeofconduct/

[Python-Dev] Re: Python-Dev Digest, Vol 204, Issue 75

[Jonathan Goble]

On Sun, Jul 12, 2020 at 1:16 PM Jim J. Jewett  wrote:

> 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 identical; the difference is in why I put that
> behavior there.
>
> match return_code:
> case -1: ...
> case 4: ...
> case x if int(x) == x:
> pass # This could be a "case _" if not for the guard
> else:
> raise TypeError("Return Code not an integer?!?: ", return_code)
>

I would write that as:

match return_code:
case -1: ...
case 4: ...
case x if int(x) != x:
raise TypeError("Return Code not an integer?!?: ", return_code)
___
Python-Dev mailing list -- python-dev@python.org
To unsubscribe send an email to python-dev-le...@python.org
https://mail.python.org/mailman3/lists/python-dev.python.org/
Message archived at 
https://mail.python.org/archives/list/python-dev@python.org/message/UPR3ZPYK5U4E5WO5BL4DBSZG52WWMG4D/
Code of Conduct: http://python.org/psf/codeofconduct/