Re: Packaging/MANIFEST.in: Incude All, Exclude .gitignore

2021-03-13 Thread Albert-Jan Roskam
   you could call a simple bash script in a git hook that syncs your
   MANIFEST.in with your .gitignore. Something like:
   echo -n "exclude " > MANIFEST.in
   cat .gitignore | tr '\n' ' ' >> MANIFEST.in
   echo "graft $(readlink -f ./keep/this)" >> MANIFEST.in
   https://docs.python.org/2/distutils/sourcedist.html#commands
   On 1 Mar 2021 06:05, Abdur-Rahmaan Janhangeer 
   wrote:

 Greetings list,

 SInce i have a .gitignore, how do i exclude
 all files and folders listed by my gitignore?
 How do i include everything by default?

 Kind Regards,

 Abdur-Rahmaan Janhangeer
 about  | blog
 
 github 
 Mauritius
 --
 https://mail.python.org/mailman/listinfo/python-list
-- 
https://mail.python.org/mailman/listinfo/python-list


pygame font issue

2021-03-13 Thread Quentin Bock
Code that contains the problem:

score_value = 0
font = pygame.font.SysFont('freesansbold.ttf', 32)

error:
in font_constructor  font = Font(fontpath, size)
pygame.error: font not initialized
Can someone explain why it's saying font not initialized and provide a
solution?
I have tried typing in the direct file path of the font but that didn't
work, nor did using SysFont
-- 
https://mail.python.org/mailman/listinfo/python-list


Re: pygame font issue

2021-03-13 Thread MRAB

On 2021-03-13 15:20, Quentin Bock wrote:

Code that contains the problem:

score_value = 0
font = pygame.font.SysFont('freesansbold.ttf', 32)

error:
in font_constructor  font = Font(fontpath, size)
pygame.error: font not initialized
Can someone explain why it's saying font not initialized and provide a
solution?
I have tried typing in the direct file path of the font but that didn't
work, nor did using SysFont

In your previous post you said that your code was "almost identical" to 
what was in the tutorial, so the problem is probably in the difference. 
You haven't provided enough detail (code) for any of us to identify the 
problem.

--
https://mail.python.org/mailman/listinfo/python-list


Re: IDLE python

2021-03-13 Thread Terry Reedy

On 3/11/2021 10:28 AM, Yoosuf Oluwatosin via Python-list wrote:


I have tried to startup my IDLE python severally but it keeps giving the 
following message:
IDLE’s  subprocess didn’t make connection. See the ‘Startup Failure’ section of 
the IDLE doc online at 
https://docs.python.org/3/library/idle.html#startup-failure.
I have gone to the page and followed all the procedures listed there but there is still no change. 


Did you try starting from a command line?

I need help on this.

I included in that page every reason and remedy I knew or could find on 
stackoverflow.  But what OS and Python version?  How did you try to 
start IDLE?  What happens with "python -m idlelib -e" on a command line 
(where 'python' is the word to start 3.x)?


--
Terry Jan Reedy


--
https://mail.python.org/mailman/listinfo/python-list


Re: Uninstall error

2021-03-13 Thread Peter Pearson
On Fri, 12 Mar 2021 17:52:33 +, Premmy  wrote:
> Hi. I am trying to uninstall python on my computer because i found a better
> one but its not getting deleted from control panel. can you please help me

Windows?  Apple?  Linux?

-- 
To email me, substitute nowhere->runbox, invalid->com.
-- 
https://mail.python.org/mailman/listinfo/python-list


Re: Why assert is not a function?

2021-03-13 Thread Richard Damon
On 3/12/21 8:58 AM, Chris Angelico wrote:
> On Sat, Mar 13, 2021 at 12:11 AM Richard Damon  
> wrote:
>> On 3/12/21 12:31 AM, Chris Angelico wrote:
>>> On Fri, Mar 12, 2021 at 3:53 PM Cameron Simpson  wrote:
 For me, try/except is for when something might reasonably "go wrong" in
 normal use, even niche normal use. Whereas assert is for things which
 should _never_ occur. Roughly, again for me, try/except if for catching
 misuse and assert is for catching misdesign/misimplementation.
>>> Something like that, yeah. An assertion failure represents a bug *in
>>> this code*, something that shouldn't ever happen. If it's possible to
>>> trigger the failure with some other piece of code (calling something
>>> with bad arguments, or whatever), then assert is the wrong tool for
>>> the job. Similarly, if you find yourself catching AssertionError
>>> anywhere outside of unit testing, something is horribly wrong
>>> somewhere :)
>>>
>>> ChrisA
>> Chris, I would disagree with that statement. An assert says that there
>> is something wrong with THE code, not THIS code. It is perfectly
>> reasonable, and good defensive programming, to assert on the
>> per-conditions to the procedure at its beginning.
>>
>> Now, it may be true that a 'friendlier' procedure may be defined to
>> check some of these and return an error, but that then locks that
>> behavior into the API, so the cost of the check becomes an absolute
>> requirement.
>>
> It's perfectly reasonable to put "if condition: raise Blah", but is it
> really reasonable to use the assert statement, which (a) might not be
> run, and (b) raises a very generic exception? Make assertions about
> your own code, not other people's.
>
> ChrisA

My issue with that is that I feel that if the program raises an
exception, if SHOULD document what exceptions it raises and under what
conditions. That means that the detection of bad parameters has now been
moved from being an 'improper' use of the module, to being defined to be
checked for, and thus now a required part of the API.

Exceptions are designed for errors that might be correctable by outer
layers, program errors that you catch with assert tend not to fall into
that category.

Asserts indicate that there is a programming error that has been
detected, and the operation should be aborted. The exception generated
will not be used to 'correct' the error, but might reformat the assert
message and facilitate its reporting, or for an interactive program,
perhaps provide a path for the user to save his work or work around the
program bug.

The are conceptually very different sorts of things, and should not be
interchanged.

Note, it is often hard to tell if the 'impossible' state you ended up in
is truly a fault with your own code or the code that is calling you, so
often the detecting of bad parameters is really akin to detecting your
routine has gotten into a state it should not be in, the only difference
is you have detected this before you have done anything, and thus help
locate where the bug is.

-- 
Richard Damon

-- 
https://mail.python.org/mailman/listinfo/python-list


Re: pygame font issue

2021-03-13 Thread Irv Kalb
You need to initialize the font system with this line before you attempt to 
load a font:

pygame.font.init()

Irv

> On Mar 13, 2021, at 8:11 AM, MRAB  wrote:
> 
> On 2021-03-13 15:20, Quentin Bock wrote:
>> Code that contains the problem:
>> score_value = 0
>> font = pygame.font.SysFont('freesansbold.ttf', 32)
>> error:
>> in font_constructor  font = Font(fontpath, size)
>> pygame.error: font not initialized
>> Can someone explain why it's saying font not initialized and provide a
>> solution?
>> I have tried typing in the direct file path of the font but that didn't
>> work, nor did using SysFont
> In your previous post you said that your code was "almost identical" to what 
> was in the tutorial, so the problem is probably in the difference. You 
> haven't provided enough detail (code) for any of us to identify the problem.
> -- 
> https://mail.python.org/mailman/listinfo/python-list

-- 
https://mail.python.org/mailman/listinfo/python-list


Re: Uninstall error

2021-03-13 Thread Mats Wichmann

On 3/12/21 10:52 AM, Premmy wrote:

Hi. I am trying to uninstall python on my computer because i found a better
one but its not getting deleted from control panel. can you please help me


As already noted, it's really important to learn to give good details 
when asking for help, people who are going to respond to you aren't in 
your head, they don't know what you know and what has happened. Knowing 
the right level of detail to give isn't actually easy, you can give too 
little or too much and either way it will confuse folks.


Personally, I don't know of any place where Python goes into a "control 
panel".  ???


If you're on Windows, there are tools... search for this pattern: "Fix 
problems that block programs from being installed or removed", it 
directs you to an official fixit that cleans up the installer state, and 
if it can't spot a problem itself, lets you give it the name of the 
thing you want to nuke. On WIndows, it's usually a problem with the 
state of the installation system, not with Python itself.


"because I found a better one"  ... what does that mean? We have no idea.

--
https://mail.python.org/mailman/listinfo/python-list


PYTHONBREAKPOINT=remote_pdb.set_trace

2021-03-13 Thread Haroldo Stenger
hi, I'm using the new PYTHONBREAKPOINT=remote_pdb.set_trace feature in python 
3.9.2. After breakpoint() is reached, the telnet server is enabled and I can 
connect to the debugger. Then f.i. I do 'cont' for resuming execution, and when 
the breakpoint() is reached again, the telnet session is stalled. I telnet 
again, and then I can type debug commands again, and the former telnet session 
is closed. After a 'cont' the same repeats. Is that how it is meant to work ? 
What am I missing or getting wrong? Any help is highly appreciated

ps. I now understand that under the PYTHONBREAKPOINT=remote_pdb.set_trace , the 
interpreter will set a different telnet server when breakpoint() is reached. 
That's propably not what one wants under normal functioning. But then, how does 
one set a new breakpoint without interrupting the debugging session flow?

thanks a lot

Haroldo
-- 
https://mail.python.org/mailman/listinfo/python-list