Re: [Python-Dev] The new and improved PEP 572, same great taste with 75% less complexity!

[Jim F.Hilliard]

FWIW There's an existing issue (bpo 29652
) for the order of evaluation in
dict-comps.



Best Regards,

Jim Fasarakis Hilliard

On Thu, Apr 26, 2018 at 7:06 PM, Chris Angelico  wrote:

> On Fri, Apr 27, 2018 at 2:02 AM, Guido van Rossum 
> wrote:
> > Maybe the order for d[k] = v should also be reconsidered?
>
> If so, it would be something like:
>
> 1) Evaluate d
> 2) Evaluate k
> 3) Evaluate v
> 4) Call d.__setitem__(k, v), via slots etc
>
> In a vacuum, I don't have a problem with that. But I suspect that it'd
> break more code than the comprehensions changes do.
>
> ChrisA
> ___
> 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/d.
> f.hilliard%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] GitHub migration scheduled for Friday

[Jim F.Hilliard]

That's great, congratulations! I believe this change will make it way
easier for people to get involved!

A small question, since people can now submit new issues via pulls instead
of going to bugs.python.org, what will be the purpose of the latter?

As I skimmed through cpython-devguide.readthedocs.io I've see the issue
tracker being referenced in certain areas (File a bug section, Reviewing)
so I'm not sure I understand how they overlap.
___
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] Translated Python documentation

[Jim F.Hilliard]

I've recently been translating the Tutorial in Greek as a side thing that
also helps me catch some doc bugs :-). So it's an obvious +1 from me.

I really like this idea and would like to see it come to fruition. I think
some issues need to be addressed first, though:

Where should these translated docs live and how does one make it clear to
users reading them that doc bugs shouldn't be submitted to the main bug
tracker/github repo?

these are just two that popped in my head.

It would be great if this went forward, many people will find the path to
learning Python much much easier to walk if the documentation was written
in a language they are comfortable in.



Best Regards,

Jim Fasarakis Hilliard
*d.f.hilli...@gmail.com  | dimitrisjim.github.io
*


  




On Fri, Feb 24, 2017 at 12:02 PM, Nick Coghlan  wrote:

> On 23 February 2017 at 02:15, Victor Stinner 
> wrote:
>
>> 2017-02-22 16:40 GMT+01:00 Antoine Pitrou :
>> > As long as you are asking for "moral" support and not actually
>> > vouching for the accuracy of third-party translations, then +1 from me.
>>
>> The main complain about these translations is the accuracy.
>>
>> My bet is that making these translations "official" and more visible
>> (at docs.python.org) would make them more popular, and so indirectly
>> help to recruit new contributors. Slowly, the number of translated
>> pages should increase, but the overall translation quality should also
>> increase. That's how free software are developed, no? :-)
>>
>
> +1 from me for these reasons, and those Facundo gives: we want folks to be
> able to learn at least the basics of Python *before* they learn English
> (even if learning English remains a pre-requisite for tapping into the full
> capabilities of both the language and its ecosystem).
>
> Cheers,
> Nick.
>
> --
> Nick Coghlan   |   ncogh...@gmail.com   |   Brisbane, Australia
>
> ___
> 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/d.
> f.hilliard%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] Translated Python documentation

[Jim F.Hilliard]

I've recently been translating the Tutorial in Greek as a side thing that
also helps me catch some doc bugs :-). So it's an obvious +1 from me.

I really like this idea and would like to see it come to fruition. I think
some issues need to be addressed first, though:

Where should these translated docs live and how does one make it clear to
users reading them that doc bugs shouldn't be submitted to the main bug
tracker/github repo?

these are just two that popped in my head.

It would be great if this went forward, many people will find the path to
learning Python much much easier to walk if, at least the tutorial, was
written in a language they are comfortable in.
___
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] mention aenum in the Enum docs?

[Jim F.Hilliard]

Being the one who left the comment, I'm all for adding it.

The reason I wondered why it was not there was because I was aware you are
the author of both so, I believe, the con of it being a 3rd party library
is minimized. I've also seen plenty of people asking around for more
advanced usages of Enums so it's better to direct them to a library that
not only covers many cases but is also reliable due to you authoring it.

I'm afraid that the alternative of adding it to the wiki (as you replied)
would make no tangible difference on its visibility.




On Wed, May 10, 2017 at 1:47 AM, Brett Cannon  wrote:

>
>
> On Tue, 9 May 2017 at 10:59 Mark Lawrence via Python-Dev <
> python-dev@python.org> wrote:
>
>> On 09/05/2017 18:05, Ethan Furman wrote:
>> > A comment on a recent SO answer [1] wondered why my aenum library wasn't
>> > mentioned in the docs to help guide people that needed/wanted more
>> > advanced Enum options to it.  I responded that Python was not in the
>> > habit of mentioning third-party libraries in the docs.
>> >
>> > However, I thought I would double-check here to see if it might be a
>> > good idea.
>> >
>> > Pros:
>> > - drop-in replacement for the stdlib Enum
>> > - has many advanced features such as
>> >- auto __init__ building
>> >- multi-value members
>> >- duplicate value but non-aliasing members
>> >- etc.
>> > - I'm the primary/only maintainer for both
>> >
>> > Cons:
>> > - third-party library
>> >
>> > Thoughts?
>> >
>> > --
>> > ~Ethan~
>> >
>> >
>> > [1] http://stackoverflow.com/a/43855536/208880
>>
>> The precedent is all ready set as the third-party regex module gets a
>> mention here https://docs.python.org/3/library/re.html and the requests
>> package here https://docs.python.org/3/library/urllib.request.html.
>>
>
> Mark's right that we already do this for select modules. Since aenum is by
> the author of enum to add things that don't fit in the stdlib and has been
> out for years (i.e. by you, Ethan :) , I see nothing wrong with linking to
> 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/d.
> f.hilliard%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: PEP 622: Structural Pattern Matching

[Jim F.Hilliard]

I'm also not a big fan of the 'else' proposal.

Context matters and in the context of match expressions a case with a
wildcard pattern makes sense, an else, not so much.
___
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/XYF2H2ACRMBEULHGPDHZIGFZFG56DHHH/
Code of Conduct: http://python.org/psf/codeofconduct/

[Python-Dev] Re: The Anti-PEP

[Jim F.Hilliard]

A natural question that arises is who will be responsible for authoring it?
I'd guess anyone with a strong enough opinion (and there's no shortage of
those) could be the one who does it.

Separating bikeshedding from refusals/rejections definitely has merit
though, especially for the person making the final decision.

Best Regards,
Jim Fasarakis Hilliard


On Thu, Jun 25, 2020 at 2:08 PM Mark Shannon  wrote:

> Hi,
>
> I'd like to propose the "Anti-PEP".
>
> As I'm sure you've all noticed, contentious PEPs like 572, and now 622,
> generate a lot of email discussion.
> It's easy to feel that people's opinions are being dismissed and that
> legitimate criticisms aren't being heard.
> Conversely, PEP authors may feel they are being bombarded with
> criticism, which can be overwhelming.
>
> The acceptance, or rejection, of a PEP should be a cool technical
> decision. Whilst there may be considerations of aesthetics and usability
> that make it difficult to objective, the goal should be to choose what
> is best for the language in the long term.
>
> When deciding on PEP 484, I had to decide between a formally written PEP
> on one hand, and a mass of emails and informal polls I had done at
> conferences, on the other.
> I hope I made the right decision.
>
> Whether the ultimate decision is made by the steering committee or by a
> PEP delegate, it is hard to make a decision between the pros and cons,
> when the pros are in a single formal document and the cons are scattered
> across the internet.
>
> An Anti-PEP is a way to ensure that those opposed to a PEP can be heard
> and, if possible, have a coherent voice.
> Hopefully, it would also make things a lot less stressful for PEP authors.
>
>
> The Anti-PEP
> 
>
> The Anti-PEP is a single document that describes why a particular PEP
> should be rejected.
>
> An Anti-PEP is not a counter PEP. A counter PEP suggests an alternative
> solution to the same problem and will often share the same motivation as
> the original PEP. An Anti-PEP would usually reject the motivation or
> rationale, either as insufficient or as incorrect.
>
> An example of a counter PEP is 576, which was a counter to 575. The
> motivation was the same, but means proposed was quite different. As a
> result of the ensuing to and fro, we ended up with PEP 590, which was a
> clear improvement.
>
> I don't have an example of an Anti-PEP.
>
> We could start with PEP 611, https://www.python.org/dev/peps/pep-0611/.
> There were many criticisms of it on this mailing list, and I can promise
> the PEP author won't be upset by an Anti-PEP :)
> Anyone care to volunteer?
>
> Cheers,
> Mark.
> ___
> 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/JVKWNZEDRXR2IF3KM2JNUF6WT7WETUVK/
> 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/KKU6JNU2F7XXEZ6QSOOUJZ6SYMOREMRF/
Code of Conduct: http://python.org/psf/codeofconduct/

[Python-Dev] Re: [Python-ideas] Re: Amend PEP-8 to require clear, understandable comments instead of Strunk & White Standard English comments

[Jim F.Hilliard]

I believe I'm not the only one with this question but, how is Strunk &
White connected with white supremacy?

Scanning through this thread, its wikipedia page and doing quick google
search, I wasn't able to find something tangible.


Best Regards,

Jim Fasarakis Hilliard
___
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/3FUFDUX3Z4LXCTFSXCNIPNBED2IFDJ23/
Code of Conduct: http://python.org/psf/codeofconduct/

[Python-Dev] Re: [Python-ideas] Re: Amend PEP-8 to require clear, understandable comments instead of Strunk & White Standard English comments

[Jim F.Hilliard]

On Mon, Jun 29, 2020 at 2:50 PM Paul Sokolovsky  wrote:

>
> I wouldn't be surprised if the only connection between them is the word
> "white".
>
>
I would be *very* surprised. This seems very foreign to me as a European.
___
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/UWPXOYJTNMBNDAG6JX6ZD5YUM6FHTVIB/
Code of Conduct: http://python.org/psf/codeofconduct/

[Python-Dev] Re: [Python-ideas] Re: Amend PEP-8 to require clear, understandable comments instead of Strunk & White Standard English comments

[Jim F.Hilliard]

On Mon, Jun 29, 2020 at 4:21 PM Nathaniel Smith  wrote:

>
> It's not Strunk and White per se, it's the idea of enforcing "standard
> English", where "standard" here means "talks like a American with an
> Ivy league education".
>
You all are displaying breathtakingly levels of ignorance here.
>

I definitely am, hence why I asked the question in the first place.

As it is currently written it isn't clearly understandable to non-US based
people. I just wish that the original email or the commit message did a
better job in justifying this for the rest of us.

But let's let this thread die here.
>

+1
___
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/F43TU3MMBK4NO6UKHNUDFPTUUVAEINK7/
Code of Conduct: http://python.org/psf/codeofconduct/

[Python-Dev] Re: Recent PEP-8 change

[Jim F.Hilliard]

On Tue, 30 Jun 2020, 17:36 Piper Thunstrom,  wrote:

It specifically
> was chosen to avoid "lower class" usages and things like AAVE (though
> that term would not exist for decades after the movement reached a
> furor).


I mean, surely not only did it exclude "lower class" terms and AAVE
(African American vernacular English, for the rest who don't do well with
acronyms) it also excluded a number of dialects used by groups of all
colours and backgrounds. I don't think I'd find any Australian words in
there nor any Scottish ones, would I?

I don't see how standard English is a white supremacist construct. I see it
as an intersection of most of the dialects around, as a means to optimize
communication by following a common set of guidelines.

Can you elaborate on why you view this as being white supremacy?
___
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/XSWX7ETERNPLDDOFM65DSMAQWGPDFLUU/
Code of Conduct: http://python.org/psf/codeofconduct/

[Python-Dev] Re: Recent PEP-8 change

[Jim F.Hilliard]

On Thu, Jul 2, 2020 at 9:51 PM Ethan Furman  wrote:

> But the text in question said nothing about gender issues -- it was about
> race issues.  Can anyone shed light on that?  If there is something I need
> to learn I would like to learn it.
>

Exactly.

The explanation so far has been that it is not S&W that is a relic of white
supremacy. The Standard English, which it advocates, is. Explaining how
that is would make the commit message sensible, to me at least. (though the
fact that the description of the PR differs from the commit message was
problematic nonetheless.)
___
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/IG5NTJI5KF3247LRRVWI6BNFSOQWVUCU/
Code of Conduct: http://python.org/psf/codeofconduct/