RE: Subject: Are there any easy-to-use Visual Studio C# WinForms-like GUI designers in the Python world for Tk?

2023-12-29 Thread Greg Walters via Python-list
> I'm used to C# WinForms, which has an easy-to-use drag-and-drop
GUI designer in Visual Studio. Is there anything similar for Tk? How
about Qt? What do you recommend as the easiest way to create GUI programs
in Python, similar to the ease of use of C# WinForms?

I can't say much for Qt other than there is a GUI designer for it, but I
don't know much about it.

As to the portion of your question about Python and Tkinter, YES!
The project is called PAGE and it is a drag and drop designer using the Tk
and ttk toolkits (basically Tkinter).

It's been around for many years, is completely FREE and open source, the
source code is included and works on Windows, Linux and Mac OS.

The current version is 7.6 and you can find it at
https://sourceforge.net/projects/page/ and it has been downloaded over 2000
times just in December, and over 26,000 times in 2023.

There is a TONNE of examples, full documentation and a number of
tutorials.  The Sourceforge acts as the main help site, but there is also a
Discord site dedicated to help and support.

I sincerely hope this helps!

Greg Walters


-- 
*My memory check bounced*



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


Re: Subject: problem activating python

2022-12-17 Thread Michael Torrie
On 12/17/22 15:45, Anne wrote:
>I tried several times to install and use python for youtube views with Tor
>using Youtube tutorials but I keep getting error after error. Please help
>me.
>regards Dimpho

Given the lack of any information in your post, I can only assume you're
trying to get Python installed on Windows.  Please read this page and
post here if you have any questions:
https://docs.python.org/3/using/windows.html

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


Re: Subject: problem activating python

2022-12-17 Thread Mats Wichmann

On 12/17/22 15:45, Anne wrote:

I tried several times to install and use python for youtube views with Tor
using Youtube tutorials but I keep getting error after error. Please help
me.
regards Dimpho


Folks around here tend to be pretty helpful.  But only if you describe 
the problem in a way they can help with.  It's not clear what you're 
trying to do, and "I keep getting error after error" doesn't give anyone 
any information to work with.




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


Subject: problem activating python

2022-12-17 Thread Anne
   I tried several times to install and use python for youtube views with Tor
   using Youtube tutorials but I keep getting error after error. Please help
   me.
   regards Dimpho

    

    

    

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


Re: memoization (original Subject lost because mailer lost the whole thread)

2022-09-20 Thread Peter J. Holzer
On 2022-09-19 17:31:31 +, Christman, Roger Graydon wrote:
> And fortunately, Python makes memoization very easy, by using a
> dictionary as a default value.   I've done that often for classroom
> purposes for cases where it makes a big difference (recursive
> Fibonacci accelerates from exponential time to linear time).   And the
> process is straightforward enough that you could even define a
> decorator that could be applied to any function you choose.

Such a decorator is already part of the Python standard library:

https://docs.python.org/3/library/functools.html#functools.lru_cache

hp

-- 
   _  | Peter J. Holzer| Story must make more sense than reality.
|_|_) ||
| |   | h...@hjp.at |-- Charles Stross, "Creative writing
__/   | http://www.hjp.at/ |   challenge!"


signature.asc
Description: PGP signature
-- 
https://mail.python.org/mailman/listinfo/python-list


Re: memoization (original Subject lost because mailer lost the whole thread)

2022-09-19 Thread Christman, Roger Graydon
"Hen Hanna"  asked:
> so... for a few days  i've been revising this Code (in Gauche / Lisp / 
> Scheme) to make it run faster..   and last night  i could improve it enough 
> to give me the result i wantedin  72 minutes or so  (on my slow PC at 
> home).

>  ( Maybe... within a few months, i'll write the same program in Python   
> to see if it runs  10 or 20 times faster. )

> this was the first time  i've used  Caching (memoization).  - instead of  
> calculating (at run-time)Factorial(x)   and   Combination(x,y)   millions 
> of times,   i made 2 tables in advance...A simple Table-lookup  
> (Vector-ref in Scheme)  seems  100 -- 1000 times faster.

> One thought i had was...  Maybe Python's  Factorial(x) and Combination(x,y)   
>  (in  Numpy ?)  are already so fast that...   i don't have to do the  Caching 
> (memoization) ???

Memoization will generally be very fast -- since it is essentially a 
table-lookup.   If it uses a hash-table (which is common for dictionaries), it 
would be close to a constant-time access for any entry; otherwise, if it uses 
some tree structure, it might be logarithmic in the number of entries in the 
tree.

But that fast access comes at a price of storage -- linear with respect to the 
number of items stored (versus no memory cost incurred when not memoizing).

What effect this has when you call these functions "millions of times" depends 
very much one how many of those calls are on the same values.If all of the 
calls have different arguments, memoization would not find it in the table yet, 
and would have to recompute as normal -- and you would end up with no time 
savings, but a considerable memory allocation for all of those newly-cached 
values that you never retrieve.   The big wins come from asking the same 
questions repeatedly.

Now, as far as Python's functionality, I would not expect it to do any 
memoization for you.   It certainly could not predict what arguments would 
provide, but it still could still have a reasonable implementation without 
memoization.  Your Factorial(x) and Combination(x,y) would both require a time 
linear with respect to the value of x, with no memory cost incurred.

But if you were to spend most of your application asking the same questions, I 
would not expect these functions to do any caching or memoization, since I 
would expect very few applications would have enough calls to these functions 
to make it worthwhile.So calling these functions, you can expect a linear 
time for each function call, and if you expect to frequently repeat arguments, 
then you should add your own memoization for an amortized linear time.

And fortunately, Python makes memoization very easy, by using a dictionary as a 
default value.   I've done that often for classroom purposes for cases where it 
makes a big difference (recursive Fibonacci accelerates from exponential time 
to linear time).   And the process is straightforward enough that you could 
even define a decorator that could be applied to any function you choose.   I 
don't have an example handy just because I never took the time to write one.

Roger Christman
Pennsylvania State University



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


RE: [Tutor] (no subject)

2022-08-14 Thread avi.e.gross
How long?

Not fibbing but infinite is infinite and I simply so not have the time.

This is so such an EASY question that you need to show some work to interest
us.

You can do this in ANY programming language so explain if there is a reason
you ask here or ...

The real question is what you want. Do you want an algorithm, perhaps in a
function, that returns the first N numbers in the sequence, or one that can
start with an alternate sequences than the usual 0/1 or perhaps do you want
a generator that will return one number at a time infinitely, or until the
world ends, or someone pulls a power cord, whichever is sooner?


-Original Message-
From: Tutor  On Behalf Of
Phindile Julia
Sent: Sunday, August 14, 2022 12:49 PM
To: tu...@python.org
Subject: [Tutor] (no subject)

Hey how to create a Fibonacci list?
___
Tutor maillist  -  tu...@python.org
To unsubscribe or change subscription options:
https://mail.python.org/mailman/listinfo/tutor

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


Non sequitur: Changing subject line... WAS: Behavior of the for-else construct

2022-03-07 Thread Dennis Lee Bieber
On Mon, 7 Mar 2022 18:07:42 +, "Schachner, Joseph"
 declaimed the following:

>Can someone please change the topic of this thread?  No longer about for-else.
>

Pretty much anyone can change the subject of the message when replying.

But if one is using a threaded client, that thread on message
references

Message-ID: 
References: 
 <621325684.471007.1646354302...@mail.yahoo.com>
 <20220304225746.mmebv3myg5wbp...@hjp.at>
 <657845041.42944.1646437629...@mail.yahoo.com>
 <20220305001158.g7rmlyoxxtxuf...@hjp.at>
 
  <1mc72hll06itd6jnbgdherqb3thf1fk...@4ax.com>
 <20220306163951.2ozmrhfbtsktb...@hjp.at>
 
 



it will still appear under the parent message; it will only thread
differently if one's client merely sorts on subject and date/time.


-- 
Wulfraed Dennis Lee Bieber AF6VN
wlfr...@ix.netcom.comhttp://wlfraed.microdiversity.freeddns.org/
-- 
https://mail.python.org/mailman/listinfo/python-list


[issue46232] Client certificates with UniqueIdentifier in the subject break ssl.peer_certificate()

2022-02-21 Thread Ned Deily


Change by Ned Deily :


--
Removed message: https://bugs.python.org/msg413642

___
Python tracker 

___
___
Python-bugs-list mailing list
Unsubscribe: 
https://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com



[issue46232] Client certificates with UniqueIdentifier in the subject break ssl.peer_certificate()

2022-02-21 Thread 肖小小

肖小小  added the comment:

http://www.strong19.com/

--
nosy: +xiaox55066

___
Python tracker 

___
___
Python-bugs-list mailing list
Unsubscribe: 
https://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com



[issue46232] Client certificates with UniqueIdentifier in the subject break ssl.peer_certificate()

2022-02-21 Thread miss-islington


miss-islington  added the comment:


New changeset 633d0f90f933515a9fca21a38cf87a8baf8ddc7d by Miss Islington (bot) 
in branch '3.10':
bpo-46232: Fix parsing of certs with bit string in DN (GH-30351)
https://github.com/python/cpython/commit/633d0f90f933515a9fca21a38cf87a8baf8ddc7d


--

___
Python tracker 

___
___
Python-bugs-list mailing list
Unsubscribe: 
https://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com



[issue46232] Client certificates with UniqueIdentifier in the subject break ssl.peer_certificate()

2022-02-20 Thread miss-islington


Change by miss-islington :


--
nosy: +miss-islington
nosy_count: 2.0 -> 3.0
pull_requests: +29582
pull_request: https://github.com/python/cpython/pull/31454

___
Python tracker 

___
___
Python-bugs-list mailing list
Unsubscribe: 
https://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com



[issue46232] Client certificates with UniqueIdentifier in the subject break ssl.peer_certificate()

2022-02-20 Thread Christian Heimes


Christian Heimes  added the comment:


New changeset be095f6c32188bba02079d086ac8639ea37cec3c by Christian Heimes in 
branch 'main':
bpo-46232: Fix parsing of certs with bit string in DN (GH-30351)
https://github.com/python/cpython/commit/be095f6c32188bba02079d086ac8639ea37cec3c


--

___
Python tracker 

___
___
Python-bugs-list mailing list
Unsubscribe: 
https://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com



[issue46232] Client certificates with UniqueIdentifier in the subject break ssl.peer_certificate()

2022-01-03 Thread Christian Heimes


Change by Christian Heimes :


--
keywords: +patch
pull_requests: +28564
stage:  -> patch review
pull_request: https://github.com/python/cpython/pull/30351

___
Python tracker 

___
___
Python-bugs-list mailing list
Unsubscribe: 
https://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com



[issue46232] Client certificates with UniqueIdentifier in the subject break ssl.peer_certificate()

2022-01-02 Thread Christian Heimes


Change by Christian Heimes :


--
assignee: christian.heimes -> 
versions:  -Python 3.6, Python 3.7, Python 3.8

___
Python tracker 

___
___
Python-bugs-list mailing list
Unsubscribe: 
https://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com



[issue46232] Client certificates with UniqueIdentifier in the subject break ssl.peer_certificate()

2022-01-02 Thread Kacper


New submission from Kacper :

Currently all subject sets of a client certificate are treated as UTF8 strings 
using the ASN1_STRING_to_UTF8 function 
(https://github.com/python/cpython/blob/8d999cbf4adea053be6dbb612b9844635c4dfb8e/Modules/_ssl.c#L912),
 however RFC 5280 states that the UniqueIdentifier is of type BIT STRING. 
Passing a BIT STRING into the ASN1_STRING_to_UTF8 function seems to return -1 
and subsequently fail a SSL handshake.

Traceback (most recent call last):
  File "/usr/lib64/python3.6/asyncio/events.py", line 145, in _run
self._callback(*self._args)
  File "/usr/lib64/python3.6/site-packages/tornado/platform/asyncio.py", line 
138, in _handle_events
handler_func(fileobj, events)
  File "/usr/lib64/python3.6/site-packages/tornado/iostream.py", line 702, in 
_handle_events
self._handle_read()
  File "/usr/lib64/python3.6/site-packages/tornado/iostream.py", line 1471, in 
_handle_read
self._do_ssl_handshake()
  File "/usr/lib64/python3.6/site-packages/tornado/iostream.py", line 1431, in 
_do_ssl_handshake
if not self._verify_cert(self.socket.getpeercert()):
  File "/usr/lib64/python3.6/ssl.py", line 860, in getpeercert
return self._sslobj.getpeercert(binary_form)
  File "/usr/lib64/python3.6/ssl.py", line 610, in getpeercert
return self._sslobj.peer_certificate(binary_form)
ssl.SSLError: unknown error (_ssl.c:959)

(line 959 of _ssl.c corresponds to 
https://github.com/python/cpython/blob/8d999cbf4adea053be6dbb612b9844635c4dfb8e/Modules/_ssl.c#L914)

https://github.com/pyca/cryptography/issues/3542 might be of interest for 
further discussion.

--
assignee: christian.heimes
components: SSL
messages: 409532
nosy: christian.heimes, kacper
priority: normal
severity: normal
status: open
title: Client certificates with UniqueIdentifier in the subject break 
ssl.peer_certificate()
type: behavior
versions: Python 3.10, Python 3.11, Python 3.6, Python 3.7, Python 3.8, Python 
3.9

___
Python tracker 
<https://bugs.python.org/issue46232>
___
___
Python-bugs-list mailing list
Unsubscribe: 
https://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com



[issue45347] datetime subject to rounding?

2021-10-28 Thread Daniele Varrazzo


Daniele Varrazzo  added the comment:

Considering that I have found another pair of dates failing equality, and they 
are too on the last Sunday of October, the hypothesis of rounding in timezone 
code starts to look likely

Python 3.7.9 (default, Jan 12 2021, 17:26:22) 
[GCC 8.3.0] on linux

>>> import datetime, backports.zoneinfo
>>> d1 = datetime.datetime(2255, 10, 28, 7, 31, 21, 393428, 
>>> tzinfo=datetime.timezone(datetime.timedelta(seconds=27060)))
>>> d2 = datetime.datetime(2255, 10, 28, 2, 0, 21, 393428, 
>>> tzinfo=backports.zoneinfo.ZoneInfo(key='Europe/Rome'))
>>> d1 - d2
datetime.timedelta(0)
>>> d1 == d2
False

Added Python 3.7 to the affected list.

--
versions: +Python 3.7

___
Python tracker 

___
___
Python-bugs-list mailing list
Unsubscribe: 
https://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com



[issue45347] datetime subject to rounding?

2021-10-03 Thread Daniel Fortunov


Change by Daniel Fortunov :


--
nosy: +dfortunov

___
Python tracker 

___
___
Python-bugs-list mailing list
Unsubscribe: 
https://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com



[issue45347] datetime subject to rounding?

2021-10-03 Thread Joachim Jablon

Joachim Jablon  added the comment:

It may or it may not be obvious to some, but in year 5328, October 31st is the 
last Sunday of October, which in Rome, as in the rest of EU, according to the 
202X rules, means it’s the day we shift from summer time (in Rome UTC+2) to 
standard time (in Rome UTC+1). The shift supposedly happens at 3AM where it’s 
2AM, so not at midnight, but the proximity to a daylight shift moment raises 
some eyebrows. This could explain why it doesn’t happen on the year before or 
after. (I’m curious if it happens on year 5334 which has the same setup, but I 
cannot check at the moment)

--
nosy: +ewjoachim

___
Python tracker 

___
___
Python-bugs-list mailing list
Unsubscribe: 
https://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com



[issue45347] datetime subject to rounding?

2021-10-02 Thread Raymond Hettinger


Raymond Hettinger  added the comment:

Related:  https://bugs.python.org/issue44831

--
nosy: +rhettinger

___
Python tracker 

___
___
Python-bugs-list mailing list
Unsubscribe: 
https://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com



[issue45347] datetime subject to rounding?

2021-10-02 Thread Daniele Varrazzo


New submission from Daniele Varrazzo :

I found two datetimes at difference timezone whose difference is 0 but which 
don't compare equal.

Python 3.9.5 (default, May 12 2021, 15:26:36) 
[GCC 8.3.0] on linux
Type "help", "copyright", "credits" or "license" for more information.
>>> import datetime as dt
>>> from zoneinfo import ZoneInfo
>>> for i in range(3):
... ref = dt.datetime(5327 + i, 10, 31, tzinfo=dt.timezone.utc)
... print(ref.astimezone(ZoneInfo(key='Europe/Rome')) == 
ref.astimezone(dt.timezone(dt.timedelta(seconds=3600
... 
True
False
True
>>> for i in range(3):
... ref = dt.datetime(5327 + i, 10, 31, tzinfo=dt.timezone.utc)
... print(ref.astimezone(ZoneInfo(key='Europe/Rome')) - 
ref.astimezone(dt.timezone(dt.timedelta(seconds=3600
... 
0:00:00
0:00:00
0:00:00

Is this a float rounding problem? If so I think it should be documented that 
datetimes bewhave like floats instead of like Decimal, although they have 
finite precision.

--
components: Library (Lib)
messages: 403059
nosy: piro
priority: normal
severity: normal
status: open
title: datetime subject to rounding?
versions: Python 3.8, Python 3.9

___
Python tracker 
<https://bugs.python.org/issue45347>
___
___
Python-bugs-list mailing list
Unsubscribe: 
https://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com



Re: Subject: Re: Posts from gmane no longer allowed?

2021-09-26 Thread 2QdxY4RzWzUUiLuE
On 2021-09-26 at 17:40:18 -0700,
Grant Edwards  wrote:

> On 2021-09-26, Mats Wichmann  wrote:
> > On 9/26/21 10:38, 2qdxy4rzwzuui...@potatochowder.com wrote:
> >> On 2021-09-26 at 11:21:08 -0500,
> >
> >> No.  I use mbsync (formerly isync) to synchronize my gmail account with
> >> a local maildir folder, and while mbsync does send the app password
> >> (over TLS) to google every few minutes, it doesn't need the second
> >> factor.  Or at least it hasn't so far (it's been a couple of years).  I
> >> do get periodic nags from google because I'm using a "less secure"
> >> method than their web page to access my mail, but I ignore them.
> 
> Are you using an app-specific password?

Yes.  It was a hoop, but not a big one.  No, wait, I mean it wasn't a
small, flaming, poison spiked hoop; i.e., it was fairly simple to jump
through.

> > Just be aware, because It's Google, this will change again at some
> > point and you'll lose access.
> 
> Of course. That's half the fun of using Google's services. ;)

If it changes, I'll just forward incoming mail to my main (non-google)
account and not look back.  If I didn't need the account to access the
google store on my android phone, I'd would have abandoned it long ago.
-- 
https://mail.python.org/mailman/listinfo/python-list


Re: Subject: Re: Posts from gmane no longer allowed?

2021-09-26 Thread Grant Edwards
On 2021-09-26, Mats Wichmann  wrote:
> On 9/26/21 10:38, 2qdxy4rzwzuui...@potatochowder.com wrote:
>> On 2021-09-26 at 11:21:08 -0500,
>
>> No.  I use mbsync (formerly isync) to synchronize my gmail account with
>> a local maildir folder, and while mbsync does send the app password
>> (over TLS) to google every few minutes, it doesn't need the second
>> factor.  Or at least it hasn't so far (it's been a couple of years).  I
>> do get periodic nags from google because I'm using a "less secure"
>> method than their web page to access my mail, but I ignore them.

Are you using an app-specific password?

> Just be aware, because It's Google, this will change again at some point 
> and you'll lose access.

Of course. That's half the fun of using Google's services. ;)
-- 
https://mail.python.org/mailman/listinfo/python-list


Re: Subject: Re: Posts from gmane no longer allowed?

2021-09-26 Thread Mats Wichmann

On 9/26/21 10:38, 2qdxy4rzwzuui...@potatochowder.com wrote:

On 2021-09-26 at 11:21:08 -0500,



No.  I use mbsync (formerly isync) to synchronize my gmail account with
a local maildir folder, and while mbsync does send the app password
(over TLS) to google every few minutes, it doesn't need the second
factor.  Or at least it hasn't so far (it's been a couple of years).  I
do get periodic nags from google because I'm using a "less secure"
method than their web page to access my mail, but I ignore them.


Just be aware, because It's Google, this will change again at some point 
and you'll lose access.  I had a working setup that started triggering 
the less-secure warnings, but was able to ignore it after setting the 
account to allow such "insecure" access (several times, because it kept 
"forgetting" that setting, probably quite intentionally). And then after 
a while, there was no way around it, and now if my infrequently used 
setup gets triggered to sync with gmail I get "critical security alert" 
messages and nothing goes through. And it's unchangeable. I'm going to 
have to go clean it out, just been too lazy to do so.

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


Re: Subject: Re: Posts from gmane no longer allowed?

2021-09-26 Thread Ethan Furman

On 9/26/21 9:21 AM, Grant Edwards wrote:
> On 2021-09-26, Chris Angelico  wrote:

>> I'm not sure whether the policy change happened on python-list, or at
>> gmane. From the look of the error message you got, it may have
>> actually been gmane's decision. Haven't heard anything from the list
>> admins here about it, either way, so I have no idea.
>
> I'm just guessing, but I can't imagine that gmane's owner would have
> done that unless python-list itself started to refuse posts (or the
> python-list admins requested that gmane stop sending posts).

I am unaware of a change in the newsgroup <--> mailing list policy, and other newsgroup posts were coming through last 
week (it's been a light weekend).


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


Re: Subject: Re: Posts from gmane no longer allowed?

2021-09-26 Thread 2QdxY4RzWzUUiLuE
On 2021-09-26 at 11:21:08 -0500,
Grant Edwards  wrote:

> [...] Do you need the 2nd factor every time you connect to GMail via a
> browser or Android Gmail app? Or just the first time for each
> browser/device?  A bit of studying seems to be in order no matter
> what. :)

No.  I use mbsync (formerly isync) to synchronize my gmail account with
a local maildir folder, and while mbsync does send the app password
(over TLS) to google every few minutes, it doesn't need the second
factor.  Or at least it hasn't so far (it's been a couple of years).  I
do get periodic nags from google because I'm using a "less secure"
method than their web page to access my mail, but I ignore them.
-- 
https://mail.python.org/mailman/listinfo/python-list


Subject: Re: Posts from gmane no longer allowed?

2021-09-26 Thread Grant Edwards
On 2021-09-26, Chris Angelico  wrote:

Thanks for the tips on registering an application for oauth2
credentials. It sounds like I should be able to do that if I practice
my hoop-jumping a bit more.

> (But I'd still recommend an app password. Much easier.)

Yes, I really should go with the 2FA and app-password option. Do you
need the 2nd factor every time you connect to GMail via a browser or
Android Gmail app? Or just the first time for each browser/device?  A
bit of studying seems to be in order no matter what. :)

I had initially thought that oauth2 was going to be the easier row to
hoe, but it had a lot more roots and rocks than I thought.

>> I could continue to read the list with slrn, but post using something
>> like Thunderbird, but do I really want to set up a whole new MUA just
>> for one mailing list? [The other 20+ mailing lists I follow are all
>> happy with posts from gmane.]
>
> I'm not sure whether the policy change happened on python-list, or at
> gmane. From the look of the error message you got, it may have
> actually been gmane's decision. Haven't heard anything from the list
> admins here about it, either way, so I have no idea.

I'm just guessing, but I can't imagine that gmane's owner would have
done that unless python-list itself started to refuse posts (or the
python-list admins requested that gmane stop sending posts).


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


[issue44741] Pattern Matching - star subpattern with a subject derived from collections.abc.Sequence

2021-07-29 Thread Pierre Quentel


Pierre Quentel  added the comment:

I found why len() is required, it's to avoid trying to match the subject (thus 
consuming a part of it) if its length is less than the number of non-star 
patterns, as explained in the PEP.

My mistake, sorry.

--

___
Python tracker 
<https://bugs.python.org/issue44741>
___
___
Python-bugs-list mailing list
Unsubscribe: 
https://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com



[issue44741] Pattern Matching - star subpattern with a subject derived from collections.abc.Sequence

2021-07-27 Thread Pierre Quentel


Pierre Quentel  added the comment:

Oh, I did not invent this class, it is in the test script for pattern matching 
: 
https://github.com/python/cpython/blob/6948964ecf94e858448dd28eea634317226d2913/Lib/test/test_patma.py#L1932

With this class, [x, *_, y] matches, but not [x, *w, y] : this is what made me 
create this issue. Maybe it would be a good idea to change this class in 
test_patma.py ?

OTOH, if the current implementation remains the same, why does the PEP insist 
on subjects having a len() ? Could sequence patterns match a wider range of 
subjects that can be unpacked ?

--

___
Python tracker 

___
___
Python-bugs-list mailing list
Unsubscribe: 
https://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com



[issue44741] Pattern Matching - star subpattern with a subject derived from collections.abc.Sequence

2021-07-27 Thread Guido van Rossum


Guido van Rossum  added the comment:

Given that the class used to demonstrate this behavior has a bug (__len__ is 
inconsistent with __getitem__), I don't think it matters much -- if doing it 
your way is (as I suspect) slower than the current implementation for other 
(well-behaved) sequences, we should not change the implementation.

--

___
Python tracker 

___
___
Python-bugs-list mailing list
Unsubscribe: 
https://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com



[issue44741] Pattern Matching - star subpattern with a subject derived from collections.abc.Sequence

2021-07-27 Thread Pierre Quentel


Pierre Quentel  added the comment:

Thanks for the explanations, but I feel unconfortable with the fact that 
variable-length sequence patterns are implemented the same as unpacking. (sorry 
if this has been discussed before, I can't find references to the discussions 
that lead to the current version of the PEP).

There are obvious similarities between

[x, *y, z] = A

and

match A:
case [x, *y, z]:
print('ok')

but a big difference, put forward in PEP 634 : the classes supported for 
pattern matching are limited (unpacking a generator expression is possible, but 
they are not supported as subjects for sequence patterns), and the PEP 
explicitely refers to them having a len().

It seems to me that this implies that the algorithms should be different:

- for unpacking, the iterable must be completely consumed before binding the 
names on the left-hand side. If it is infinite, unpacking fails

- for variable-length sequence pattern matching (this is how I understand the 
last paragraph about them in PEP 634):
. get the subject length
. iterate one by one before the star pattern
. iterate (len(subject) - number of non-star patterns) times for the star 
pattern
. iterate one by one after the star pattern

In the second case, even if the subject never raises StopIteration, the match 
succeeds.

Does this make sense ?

--

___
Python tracker 
<https://bugs.python.org/issue44741>
___
___
Python-bugs-list mailing list
Unsubscribe: 
https://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com



[issue44741] Pattern Matching - star subpattern with a subject derived from collections.abc.Sequence

2021-07-26 Thread Steven D'Aprano


Steven D'Aprano  added the comment:

Ah, I missed that and totally misinterrpreted other comments. 
Confirmation bias at work: I saw the code I expected to see, not the 
code that was actually there :-(

All good, I agree that it is a bug in the class, not in the language. 
Sorry for the noise.

--

___
Python tracker 

___
___
Python-bugs-list mailing list
Unsubscribe: 
https://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com



[issue44741] Pattern Matching - star subpattern with a subject derived from collections.abc.Sequence

2021-07-26 Thread Brandt Bucher


Brandt Bucher  added the comment:

> All the examples that are said to go into an infinite loop work fine in 3.9. 
> [...] At the very least, the examples shouldn't swallow the IndexError and go 
> into an infinite loop.

Note that the original example posted did not include a "raise IndexError" 
branch in its __getitem__. That was class I was referring to, since the lack of 
an IndexError causes the iteration to continue forever.

As far as I know, nothing has changed about the iteration protocol in 3.10.

--

___
Python tracker 

___
___
Python-bugs-list mailing list
Unsubscribe: 
https://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com



[issue44741] Pattern Matching - star subpattern with a subject derived from collections.abc.Sequence

2021-07-26 Thread Steven D'Aprano


Steven D'Aprano  added the comment:

How is this not a regression? And a very serious one by the sound of it. All 
the examples that are said to go into an infinite loop work fine in 3.9.

(Obviously I can't check the match statement example in 3.9.)

If the Sequence Protocol really has been dropped from Python's execution model, 
shouldn't there be a PEP for such a major change in behaviour? Legacy or not, 
it is still a part of the language.

At the very least, the examples shouldn't swallow the IndexError and go into an 
infinite loop.

Brandt said:

> the destructuring is basically the same as if you had written:
> 
> [x, *w, y] = Seq()
> 
> ...which also hangs.


It works fine in 3.9, with or without inheriting from the Sequence ABC.

# Python 3.9
>>> class A:
... def __len__(self):
... return 5
... def __getitem__(self, i):
... print(i)
... if i < 5:
... return i
... raise IndexError
... 
>>> [x, *y, z] = A()
0
1
2
3
4
5
>>> x, y, z
(0, [1, 2, 3], 4)


Likewise for list(A()), etc.

The __len__ method isn't needed for iteration to work correctly. I just 
included it to match Pierre's example.

Inheriting from collections.abc.Sequence does not change the behaviour.

Still in 3.9:

>>> list(A())
0
1
2
3
4
5
[0, 1, 2, 3, 4]


I think that closing this is as Not A Bug was premature. If this isn't a bug, 
then I have no idea what counts as a bug any longer :-(

--
nosy: +steven.daprano

___
Python tracker 

___
___
Python-bugs-list mailing list
Unsubscribe: 
https://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com



[issue44741] Pattern Matching - star subpattern with a subject derived from collections.abc.Sequence

2021-07-26 Thread Brandt Bucher


Brandt Bucher  added the comment:

I agree, Pablo.

The only thing that makes me pause is that, depending on the pattern, 
*sometimes* we use iteration and *sometimes* we use indexing. That might be 
sort of surprising to classes like Seq if you change patterns or major Python 
versions and this thing starts hanging. Hopefully, though, the reason will be 
relatively easy to debug and fix.

Closing as "not a bug".

--
resolution:  -> not a bug
stage:  -> resolved
status: open -> closed
type: crash -> behavior

___
Python tracker 

___
___
Python-bugs-list mailing list
Unsubscribe: 
https://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com



[issue44741] Pattern Matching - star subpattern with a subject derived from collections.abc.Sequence

2021-07-26 Thread Pablo Galindo Salgado


Pablo Galindo Salgado  added the comment:

In general I would propose to close this as "not a bug"

--

___
Python tracker 

___
___
Python-bugs-list mailing list
Unsubscribe: 
https://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com



[issue44741] Pattern Matching - star subpattern with a subject derived from collections.abc.Sequence

2021-07-26 Thread Pablo Galindo Salgado


Pablo Galindo Salgado  added the comment:

I don't think there is anything technically wrong here. The Seq class is 
relying on the legacy version of the iterator protocol, which specifies that 
you need to raise IndexError there to stop the iteration.

For instance, this version works:

import collections.abc

class Seq(collections.abc.Sequence):
def __getitem__(self, i):
if i >= len(self):
raise IndexError
return i
def __len__(self):
return 42

match Seq():
case [x, *w, y]:
z = 0
print(z)


Also, one could argue that Seq has exactly the same problem all over the 
language. For instance

>> list(Seq())

will hang

>> [x,*y] = Seq()

will hang

and so on and so forth. So, if I am a user and I am trying to **predict** how 
this would behave based on these two experiments my conclusion would be:

"Anything that tries to iterate on this thing will hang"

I think that whatever we do, we should make it *predictable* and consistency 
across the language, and IMHO only fixing it in pattern matching doesn't make 
it predictable. Being said that, I don't think these use cases justifies a 
major overhaul of how this behaves everywhere.

--

___
Python tracker 

___
___
Python-bugs-list mailing list
Unsubscribe: 
https://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com



[issue44741] Pattern Matching - star subpattern with a subject derived from collections.abc.Sequence

2021-07-26 Thread Brandt Bucher


Brandt Bucher  added the comment:

(Raising the priority to "high" because any decision on this should ideally be 
made before the 3.10 RCs.)

Hm, interesting. This is because we use UNPACK_EX for these patterns, so the 
destructuring is basically the same as if you had written:

[x, *w, y] = Seq()

...which also hangs.

We actually have three implementations for destructuring sequences:
- Using UNPACK_EX, when there is a starred name.
- Using BINARY_SUBSCR, when there is a starred wildcard.
- Using UNPACK_SEQUENCE, when there is no star.

When using your Seq class:
- The first fails by falling into an infinite loop.
- The second works as expected.
- The third fails with a ValueError at runtime (for a length mismatch).

*If* we decide that this is a big enough problem to fix, then I think the 
easiest way of doing it is to use the BINARY_SUBSCR implementation for all 
three paths (we'll just also need to use BUILD_LIST / LIST_APPEND to actually 
collect the starred items). It will simplify the pattern compiler a bit, but I 
imagine it will also come with a performance penalty as well.

In my opinion, I don't think we should rewrite everything to support Seq 
(though my mind isn't made up entirely). Sequences are supposed to be sized and 
iterable, but Seq doesn't really support the iteration protocol correctly (it 
expects the iterating code to stop once the length is exhausted, rather than 
raising StopIteration).

I'm curious to hear opinions on whether we want to actually fix this, though. 
It seems that it will always be possible to write classes like Seq the hack our 
pattern-matching implementation with dubious sequences and mappings, so it 
really comes down to: is supporting classes like Seq worth potentially slowing 
down all other sequence patterns?

--
assignee:  -> brandtbucher
nosy: +Mark.Shannon, gvanrossum, pablogsal
priority: normal -> high

___
Python tracker 

___
___
Python-bugs-list mailing list
Unsubscribe: 
https://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com



[issue44741] Pattern Matching - star subpattern with a subject derived from collections.abc.Sequence

2021-07-26 Thread Brandt Bucher


Change by Brandt Bucher :


--
nosy: +brandtbucher

___
Python tracker 

___
___
Python-bugs-list mailing list
Unsubscribe: 
https://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com



[issue44741] Pattern Matching - star subpattern with a subject derived from collections.abc.Sequence

2021-07-26 Thread Pierre Quentel


New submission from Pierre Quentel :

This code

match range(42):
case [x, *w, y]:
z = 0

sets w to a list with 40 items : the length of the subject, minus the number of 
non-star subpatterns.

But this code (adapted from test_patma_186) enters an infinite loop

import collections.abc

class Seq(collections.abc.Sequence):
def __getitem__(self, i):
print('get item', i)
return i
def __len__(self):
return 42

match Seq():
case [x, *w, y]:
z = 0

__getitem__ gets called forever, instead of stopping when the expected number 
of items in w is reached.

--
components: Interpreter Core
messages: 398226
nosy: quentel
priority: normal
severity: normal
status: open
title: Pattern Matching - star subpattern with a subject derived from 
collections.abc.Sequence
type: crash
versions: Python 3.10, Python 3.11

___
Python tracker 
<https://bugs.python.org/issue44741>
___
___
Python-bugs-list mailing list
Unsubscribe: 
https://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com



[no subject]

2021-07-18 Thread Charles R Harris
Hi All,

On behalf of the NumPy team I am pleased to announce the release of NumPy
1.21.1.  The NumPy 1.21.1 is a maintenance release that fixes bugs
discovered after the 1.21.0 release. OpenBLAS has also been updated to
v0.3.17 to deal with arm64 problems.

The Python versions supported for this release are 3.7-3.9. The 1.21.x
series is compatible with development Python 3.10 and Python 3.10 will be
officially supported after it is released. Wheels can be downloaded from
PyPI ; source archives, release
notes, and wheel hashes are available on Github
. Linux users will
need pip >= 0.19.3 in order to install manylinux2010 and manylinux2014
wheels.

*Contributors*

A total of 11 people contributed to this release. People with a \"+\" by
their names contributed a patch for the first time.


   - Bas van Beek
   - Charles Harris
   - Ganesh Kathiresan
   - Gregory R. Lee
   - Hugo Defois +
   - Kevin Sheppard
   - Matti Picus
   - Ralf Gommers
   - Sayed Adel
   - Sebastian Berg
   - Thomas J. Fan


*Pull requests merged*

A total of 26 pull requests were merged for this release.


   - #19311: REV,BUG: Replace `NotImplemented` with `typing.Any`
   - #19324: MAINT: Fixed the return-dtype of `ndarray.real` and `imag`
   - #19330: MAINT: Replace `"dtype[Any]"` with `dtype` in the definiton
   of\...
   - #19342: DOC: Fix some docstrings that crash pdf generation.
   - #19343: MAINT: bump scipy-mathjax
   - #19347: BUG: Fix arr.flat.index for large arrays and big-endian
   machines
   - #19348: ENH: add `numpy.f2py.get_include` function
   - #19349: BUG: Fix reference count leak in ufunc dtype handling
   - #19350: MAINT: Annotate missing attributes of `np.number` subclasses
   - #19351: BUG: Fix cast safety and comparisons for zero sized voids
   - #19352: BUG: Correct Cython declaration in random
   - #19353: BUG: protect against accessing base attribute of a NULL
   subarray
   - #19365: BUG, SIMD: Fix detecting AVX512 features on Darwin
   - #19366: MAINT: remove `print()`\'s in distutils template handling
   - #19390: ENH: SIMD architectures to show\_config
   - #19391: BUG: Do not raise deprecation warning for all nans in
   unique\...
   - #19392: BUG: Fix NULL special case in object-to-any cast code
   - #19430: MAINT: Use arm64-graviton2 for testing on travis
   - #19495: BUILD: update OpenBLAS to v0.3.17
   - #19496: MAINT: Avoid unicode characters in division SIMD code comments
   - #19499: BUG, SIMD: Fix infinite loop during count non-zero on GCC-11
   - #19500: BUG: fix a numpy.npiter leak in npyiter\_multi\_index\_set
   - #19501: TST: Fix a `GenericAlias` test failure for python 3.9.0
   - #19502: MAINT: Start testing with Python 3.10.0b3.
   - #19503: MAINT: Add missing dtype overloads for object- and
   ctypes-based\...
   - #19510: REL: Prepare for NumPy 1.21.1 release.

Cheers,

Charles Harris
___
Python-announce-list mailing list -- python-announce-list@python.org
To unsubscribe send an email to python-announce-list-le...@python.org
https://mail.python.org/mailman3/lists/python-announce-list.python.org/
Member address: arch...@mail-archive.com


[issue43718] HTTP CONNECT response not subject to debug level

2021-06-28 Thread Andrei Kulakov


Andrei Kulakov  added the comment:

The PR is here:
https://github.com/python/cpython/pull/26932

--

___
Python tracker 

___
___
Python-bugs-list mailing list
Unsubscribe: 
https://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com



[issue43718] HTTP CONNECT response not subject to debug level

2021-06-28 Thread Andrei Kulakov


Change by Andrei Kulakov :


--
keywords: +patch
pull_requests: +25501
stage:  -> patch review
pull_request: https://github.com/python/cpython/pull/26932

___
Python tracker 

___
___
Python-bugs-list mailing list
Unsubscribe: 
https://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com



[issue43718] HTTP CONNECT response not subject to debug level

2021-06-28 Thread Michael Osipov


Michael Osipov <1983-01...@gmx.net> added the comment:

Thanks Andrei, please ahead and provide the PR. You'll do it faster than I do.

--

___
Python tracker 

___
___
Python-bugs-list mailing list
Unsubscribe: 
https://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com



[issue43718] HTTP CONNECT response not subject to debug level

2021-06-27 Thread Andrei Kulakov


Andrei Kulakov  added the comment:

Also note that the debug arg should be provided only if it's greater than 0, 
for cases when you might want to have connection at debug 0, and a custom 
response class with a default nonzero debug level.

--

___
Python tracker 

___
___
Python-bugs-list mailing list
Unsubscribe: 
https://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com



[issue43718] HTTP CONNECT response not subject to debug level

2021-06-27 Thread Andrei Kulakov


Andrei Kulakov  added the comment:

Michael: Thanks for the report! would you like to create a PR? If not, I can do 
that.

--
nosy: +andrei.avk

___
Python tracker 

___
___
Python-bugs-list mailing list
Unsubscribe: 
https://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com



[issue43718] HTTP CONNECT response not subject to debug level

2021-04-03 Thread Michael Osipov


New submission from Michael Osipov <1983-01...@gmx.net>:

Looking at 
https://github.com/python/cpython/blob/63c69440c7adb0de1d191a8d3d100b335d5c2f81/Lib/http/client.py#L898
self.debuglevel is not passed to response_class() and for debugging purposes I 
miss to see:
> send: b'CONNECT some-host:443 HTTP/1.0\r\n'
> send: b'\r\n'
> reply: 'HTTP/1.0 502 Bad Gateway\r\n'

reply is missing. It trivial to pass the debug level.

--
components: Library (Lib)
messages: 390139
nosy: michael-o
priority: normal
severity: normal
status: open
title: HTTP CONNECT response not subject to debug level
versions: Python 3.10, Python 3.8, Python 3.9

___
Python tracker 
<https://bugs.python.org/issue43718>
___
___
Python-bugs-list mailing list
Unsubscribe: 
https://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com



[issue25257] In subject line email library inserts unwanted space after a thousands comma in a number

2020-06-23 Thread SilentGhost


Change by SilentGhost :


--
resolution:  -> out of date
stage:  -> resolved
status: open -> closed

___
Python tracker 

___
___
Python-bugs-list mailing list
Unsubscribe: 
https://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com



[issue25257] In subject line email library inserts unwanted space after a thousands comma in a number

2020-06-23 Thread Zackery Spytz


Zackery Spytz  added the comment:

Python 2 is EOL, so I think this issue should be closed.

--
nosy: +ZackerySpytz

___
Python tracker 

___
___
Python-bugs-list mailing list
Unsubscribe: 
https://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com



[no subject]

2020-05-31 Thread Charles R Harris
Hi All,

On behalf of the NumPy team I am pleased to announce that
NumPy 1.19.0rc2 has been released. This NumPy release supports Python
3.6-3.8 and is marked by the removal of much technical debt: support for
Python 2 has been removed, many deprecations have been expired, and
documentation has been improved. The polishing of the random module
continues apace with bug fixes and better usability from Cython. Perhaps
the most interesting thing for users will be the availability of wheels for
aarch64 and PyPY.

Downstream developers should use Cython >= 0.29.16 for Python 3.8 support
and OpenBLAS >= 3.7 to avoid wrong results on the Skylake architecture. The
NumPy Wheels for this release can be downloaded from PyPI
, source archives and release
notes are available from Github
.

*Contributors*

A total of 124 people contributed to this release.  People with a "+" by
their
names contributed a patch for the first time.

   - Alex Henrie
   - Alexandre de Siqueira +
   - Andras Deak
   - Andrea Sangalli +
   - Andreas Klöckner +
   - Andrei Shirobokov +
   - Anirudh Subramanian +
   - Anne Bonner
   - Anton Ritter-Gogerly +
   - Benjamin Trendelkamp-Schroer +
   - Bharat Raghunathan
   - Brandt Bucher +
   - Brian Wignall
   - Bui Duc Minh +
   - Changqing Li +
   - Charles Harris
   - Chris Barker
   - Chris Holland +
   - Christian Kastner +
   - Chunlin +
   - Chunlin Fang +
   - Damien Caliste +
   - Dan Allan
   - Daniel Hrisca
   - Daniel Povey +
   - Dustan Levenstein +
   - Emmanuelle Gouillart +
   - Eric Larson
   - Eric M. Bray
   - Eric Mariasis +
   - Eric Wieser
   - Erik Welch +
   - Fabio Zeiser +
   - Gabriel Gerlero +
   - Ganesh Kathiresan +
   - Gengxin Xie +
   - Guilherme Leobas
   - Guillaume Peillex +
   - Hameer Abbasi
   - Hao Jin +
   - Harshal Prakash Patankar +
   - Heshy Roskes +
   - Himanshu Garg +
   - Huon Wilson +
   - John Han +
   - John Kirkham
   - Jon Dufresne
   - Jon Morris +
   - Josh Wilson
   - Justus Magin
   - Kai Striega
   - Kerem Hallaç +
   - Kevin Sheppard
   - Kirill Zinovjev +
   - Marcin Podhajski +
   - Mark Harfouche
   - Marten van Kerkwijk
   - Martin Michlmayr +
   - Masashi Kishimoto +
   - Mathieu Lamarre
   - Matt Hancock +
   - MatteoRaso +
   - Matthew Harrigan
   - Matthias Bussonnier
   - Matti Picus
   - Max Balandat +
   - Maximilian Konrad +
   - Maxwell Aladago
   - Maxwell Bileschi +
   - Melissa Weber Mendonça +
   - Michael Felt
   - Mike Taves
   - Nico Schlömer
   - Pan Jan +
   - Paul Rougieux +
   - Pauli Virtanen
   - Peter Andreas Entschev
   - Petre-Flaviu Gostin +
   - Pierre de Buyl
   - Piotr Gaiński +
   - Przemyslaw Bartosik +
   - Raghuveer Devulapalli
   - Rakesh Vasudevan +
   - Ralf Gommers
   - RenaRuirui +
   - Roman Yurchak
   - Ross Barnowski +
   - Ryan +
   - Ryan Soklaski
   - Sanjeev Kumar +
   - SanthoshBala18 +
   - Sayed Adel +
   - Sebastian Berg
   - Seth Troisi
   - Sha Liu +
   - Siba Smarak Panigrahi +
   - Simon Gasse +
   - Stephan Hoyer
   - Steve Dower +
   - Thomas A Caswell
   - Till Hoffmann +
   - Tim Hoffmann
   - Tina Oberoi +
   - Tirth Patel
   - Tyler Reddy
   - Warren Weckesser
   - Wojciech Rzadkowski +
   - Xavier Thomas +
   - Yilin LI +
   - Zac Hatfield-Dodds +
   - Zé Vinícius +
   - @Adam +
   - @Anthony +
   - @Jim +
   - @bartosz-grabowski +
   - @dojafrat +
   - @gamboon +
   - @jfbu +
   - @keremh +
   - @mayeut +
   - @ndunnewind +
   - @nglinh +
   - @shreepads +
   - @sslivkoff +

Cheers,

Charles Harris
___
Python-announce-list mailing list -- python-announce-list@python.org
To unsubscribe send an email to python-announce-list-le...@python.org
https://mail.python.org/mailman3/lists/python-announce-list.python.org/
Member address: arch...@mail-archive.com


Subject: Python Open-Source Snippets Newsletter

2020-05-23 Thread Aswin K

Hi,

I am creating a Python newsletter showcasing useful code snippets from 
popular open-source libraries. I will also be providing a runnable demo 
link to better understand the working.


Newsletter subscription link: https://www.pythonninja.xyz/subscribe

A sample snippet from the newsletter:

HTTP Request retrying with Backoffs - Technique for retrying failed HTTP 
requests.


From Google Maps Services Python 
(https://github.com/googlemaps/google-maps-services-python)


Demo link: https://repl.it/@PythonNinja/requestretries

"""
first_request_time: The time of the first request (None if no retries 
have occurred).

retry_counter: The count of retries, or zero for the first attempt.
"""

if not first_request_time:
first_request_time = datetime.now()

elapsed = datetime.now() - first_request_time
if elapsed > self.retry_timeout:
raise googlemaps.exceptions.Timeout()

if retry_counter > 0:
# 0.5 * (1.5 ^ i) is an increased sleep time of 1.5x per iteration,
# starting at 0.5s when retry_counter=0. The first retry will occur
# at 1, so subtract that first.
delay_seconds = 0.5 * 1.5 ** (retry_counter - 1)

# Jitter this value by 50% and pause.
time.sleep(delay_seconds * (random.random() + 0.5))

Subscribe here: https://www.pythonninja.xyz/subscribe

Feedbacks and criticism are welcome.
--
https://mail.python.org/mailman/listinfo/python-list


[no subject]

2020-01-17 Thread kiran chawan
Hi,  Sir my self kiran chawan studying in engineering and I have HP PC  and
windows edition is window 10, system type 64-bit operating system.  So tell
me which python version software is suitable for my PC okay and send me
that software direct link okay thank you.
-- 
https://mail.python.org/mailman/listinfo/python-list


[no subject]

2020-01-06 Thread AAKASH JANA
Julia is a rapidly progressing language directly attacking python's sweet
spot in a.i , m.l and other computational areas. I love python and want it
to remain undefeated . I think its time we create a compiler for python .
So that python can be compiled and interpreted at will . Its time we make
our snake go faster than the world.(and most importantly Julia)
-- 
https://mail.python.org/mailman/listinfo/python-list


Re: (no subject)

2020-01-06 Thread Rob Gaddi

On 1/4/20 2:29 PM, William Johnsson wrote:

Hello! My name is William and im 14 years old and live in sweden.  Im pretty 
new to programing in python and i need some help with code, (That’s why i’m 
here). But i couldn’t really find what i was searching for on the internet. I’m 
trying to write code that can check only the first line in a .txt file and 
check if it’s the same as the int 1000.   I preferably want it to be an if 
satement but anything works, i just don’t know how i should write it. I’ve been 
browsing the internet for a solution but sadly can’t seem to find a solution to 
it.

I don’t really know if this is the right way to get help or even if this email 
is for something else. Hopefully i will get some kind of response.

Best regards, William



It won't be; it can't be.  A text file contains only text.  The line you read 
from it might be the string '1000' (or more likely '1000\n', which is 4 digits 
followed by a newline character), but it cannot be the int 1000 because data has 
types.


str(1000) gives you '1000', because ints can be converted to strings. 
int('1000') gives you 1000 because and strings consisting only of digits can be 
converted to ints.  So the two types are convertible into one another.  But 
that's a thing you need to do explicitly.  If x is a thing you just read from a 
text file then


if x == 1000:

can never be true.
--
https://mail.python.org/mailman/listinfo/python-list


[no subject]

2020-01-04 Thread William Johnsson
Hello! My name is William and im 14 years old and live in sweden.  Im pretty 
new to programing in python and i need some help with code, (That’s why i’m 
here). But i couldn’t really find what i was searching for on the internet. I’m 
trying to write code that can check only the first line in a .txt file and 
check if it’s the same as the int 1000.   I preferably want it to be an if 
satement but anything works, i just don’t know how i should write it. I’ve been 
browsing the internet for a solution but sadly can’t seem to find a solution to 
it.

I don’t really know if this is the right way to get help or even if this email 
is for something else. Hopefully i will get some kind of response.

Best regards, William
-- 
https://mail.python.org/mailman/listinfo/python-list


[no subject]

2019-08-05 Thread arash kohansal
Hello i have a laptob and working with windows 10 ive installed python in
my pc and ive already check the path choice pary in the installation im
working with microsoft visual studio code but it cant find the python
installed extention and it doesnt have the green star on the top of python
language
-- 
https://mail.python.org/mailman/listinfo/python-list


[no subject]

2019-06-24 Thread Sagar Jape
I'm not able to install pip in my pc it gives following error. what should
I do?
-- 
https://mail.python.org/mailman/listinfo/python-list


Re: (no subject)

2019-05-31 Thread Alister via Python-list
On Wed, 29 May 2019 08:07:06 +0530, Sri Tharun wrote:

> Why I am unable to install packages

because you are doing it wrong
-- 
https://mail.python.org/mailman/listinfo/python-list


[no subject]

2019-05-28 Thread Sri Tharun
Why I am unable to install packages
-- 
https://mail.python.org/mailman/listinfo/python-list


[issue33971] os.mknod is subject to "umask"

2019-05-06 Thread anthony shaw


anthony shaw  added the comment:

NB: This issue would be good for PyCon sprints

--
nosy: +anthonypjshaw

___
Python tracker 

___
___
Python-bugs-list mailing list
Unsubscribe: 
https://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com



[issue33971] os.mknod is subject to "umask"

2019-05-06 Thread anthony shaw


Change by anthony shaw :


--
assignee: docs@python -> Mariatta
nosy: +Mariatta

___
Python tracker 

___
___
Python-bugs-list mailing list
Unsubscribe: 
https://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com



Re: (no subject)

2019-04-19 Thread Luuk

On 19-4-2019 16:37, Tamara Berger wrote:

Hi Python-List,

What code can I use to break out of a program completely, and not just out
of a loop? I wrote code with 3 conditions for saving for a downpayment. The
first addresses cases that don't meet the minimum condition; i.e., enough
money to save for a downpayment within the allotted time. It has its own
print line, but also executes the irrelevant print lines for the other two
conditions.

Thanks,
Tamara



cond1 = 1;
cond2 = 1;
cond3 = 1;

if cond1:
  if cond2:
if cond3:
  print("All OK")
else:
  print("cond3 NOK")
  else:
print("cond2 NOK")
else:
  print("cond1 NOK")



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


Re: (no subject)

2019-04-19 Thread Luuk

On 19-4-2019 16:37, Tamara Berger wrote:

Hi Python-List,

What code can I use to break out of a program completely, and not just out
of a loop? I wrote code with 3 conditions for saving for a downpayment. The
first addresses cases that don't meet the minimum condition; i.e., enough
money to save for a downpayment within the allotted time. It has its own
print line, but also executes the irrelevant print lines for the other two
conditions.

Thanks,
Tamara



cond1 = 1;
cond2 = 1;
cond3 = 1;

if cond1:
  if cond2:
if cond3:
  print("All OK")
else:
  print("cond3 NOK")
  else:
print("cond2 NOK")
else:
  print("cond1 NOK")



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


[no subject]

2019-04-19 Thread Tamara Berger
Hi Python-List,

What code can I use to break out of a program completely, and not just out
of a loop? I wrote code with 3 conditions for saving for a downpayment. The
first addresses cases that don't meet the minimum condition; i.e., enough
money to save for a downpayment within the allotted time. It has its own
print line, but also executes the irrelevant print lines for the other two
conditions.

Thanks,
Tamara
-- 
https://mail.python.org/mailman/listinfo/python-list


[no subject]

2019-04-18 Thread trisha guillot


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


[no subject]

2018-12-11 Thread Alperen Eroğlu
I subscribed to python list and now I want to state my requeat.I downloaded
Python because I wanted to learn how to code.I also downloaded a text
editor specially designed for coding Python(which iscalled Pycharm)
.both of the softwares and my Windows 10 software was he latest.I got into
Python and it asked me which text file I was going to use to edit files,but
the app(which is Python)couldn't find where the files were located.Hope I
shall get a reply sir

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


[issue34954] Getting an email's subject is error-prone

2018-10-11 Thread Alex Corcoles

Alex Corcoles  added the comment:

Duh, I'm an idiot, I only tested policy.HTTP and *NOT* supplying a policy 
(which I believed was equivalent to using policy.default).

policy.default and policy.SMTP do indeed produce a newline-less subject indeed.

I only tested policy.HTTP because the docs talk about unlimited line-length, 
but that's a problem of the docs, but rather, a problem of my idiocy.

Given this, I agree with everything you said. Personally I'd prefer if 
policy.default was the default, but I guess that won't change due to backwards 
compatibility reasons and I guess it'd be excessive to create a new set of 
function calls and deprecate the old, so I'm happy if this remains closed.

Apologies for my stupidity,

Álex

--

___
Python tracker 
<https://bugs.python.org/issue34954>
___
___
Python-bugs-list mailing list
Unsubscribe: 
https://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com



[issue34954] Getting an email's subject is error-prone

2018-10-11 Thread R. David Murray


R. David Murray  added the comment:

I'm guessing you got confused by the fact that the HTTP policy doesn't *add* 
new lines when *serializing*.  If you can point to the part of the docs you 
read that produced that confusion, maybe we can improve it.

--

___
Python tracker 

___
___
Python-bugs-list mailing list
Unsubscribe: 
https://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com



[issue34954] Getting an email's subject is error-prone

2018-10-11 Thread R. David Murray


R. David Murray  added the comment:

Can you demonstrate that policy.default and policy.SMTP produce a subject with 
newlines?  If they do, that is a serious bug.

Please don't reopen the issue.  I'll reopen it if you convince me there is a 
bug :)

The statement you suggest we add is not appropriate[*], since the python3 email 
library *is* a high level library now.  If it isn't handling something for you 
when you use policy.default or policy.SMTP, then that is a bug.  (Well, it's 
MIME Multipart handling still leaves something to be desired...you still have 
to know more than is optimal about multiparts, but the hooks are there for 
someone to improve that aspect further.)

[*] The part about the protocol is certainly true, though :)

--
status: open -> closed

___
Python tracker 
<https://bugs.python.org/issue34954>
___
___
Python-bugs-list mailing list
Unsubscribe: 
https://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com



[issue34954] Getting an email's subject is error-prone

2018-10-11 Thread Alex Corcoles

Alex Corcoles  added the comment:

Well, I think that having to choose the "HTTP" policy to get a message 
subject's without newlines goes against the expectations of anyone who is not 
well knowledgeable of email.

It's not very easy to deduct that, out of all the available policies, HTTP is 
the one that has this effect (or writing your own).

It's not obvious that a subject can have newlines, as I don't think I've ever 
seen a MUA that does not hide them.

You can be bitten quite easily by that (we have, more than once).

It's the stdlib's maintainers' prerrogative to decide that they are going to 
provide low-level libraries (and in general, I agree with that, high-level 
stdlibs have a lot of problems), but at least I'd include some warning like:

"Email is an old and annoying protocol, and parsing email is full of annoyances 
and exceptions. email provides low-level building blocks to handle email in 
detail. If you want high-level processing we advise you to look at libraries 
that build on it".

In any case, email.policy provides more hints as to headers being wordwrapped, 
and while it's not ideal, it certainly is an improvement WRT to Python 2, so 
this bug has helped me and I hope maybe someone will read it when Googling for 
the same problem, so while I think some more could be done, if you close this I 
won't complain.

Thanks,

Álex

--
status: closed -> open

___
Python tracker 
<https://bugs.python.org/issue34954>
___
___
Python-bugs-list mailing list
Unsubscribe: 
https://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com



[issue34954] Getting an email's subject is error-prone

2018-10-10 Thread R. David Murray


R. David Murray  added the comment:

The new policies *make* the email library that higher level library, that was 
pretty much the whole point :)  I don't know how to make getting the fully 
decoded subject more intuitive than:

  msg['subject']

The fact that you have to specify a policy is due to backward compatibility 
concerns, and there's not really any way around that.  That's the only 
difference between your two examples (other than the fact that the second one 
does what you want :).

Note that you *really* want to be using message_from_bytes, and for email 
either policy.default or policy.SMTP.  This *is* documented in the python3 
docs.  If you don't find them clear, then an issue to improve the docs would be 
welcome.

Since python2 is approaching EOL, we could also start transitioning to 
policy.default actually being the *default*.  That will take two release cycles 
(one that will generate a deprecation notice that the default is going to 
change, and another that will actually make the change).

--
status: open -> closed

___
Python tracker 
<https://bugs.python.org/issue34954>
___
___
Python-bugs-list mailing list
Unsubscribe: 
https://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com



[issue34954] Getting an email's subject is error-prone

2018-10-10 Thread Alex Corcoles


Alex Corcoles  added the comment:

To clarify (and maybe help someone which might come across), you mean:

In [1]: message_text = """To: a...@corcoles.net
   ...: Subject: ** ACKNOWLEDGEMENT Host Alert: archerc7.bcn.int.pdp7.net is 
DOWN
   ...:  **
   ...: User-Agent: Heirloom mailx 12.5 7/5/10
   ...: MIME-Version: 1.0
   ...: Content-Type: text/plain; charset=us-ascii
   ...: Content-Transfer-Encoding: 7bit
   ...: 
   ...: * Nagios *
   ...: """
In [2]: import email
In [4]: message = email.message_from_string(message_text)
In [5]: message.get('Subject')
Out[5]: '** ACKNOWLEDGEMENT Host Alert: archerc7.bcn.int.pdp7.net is DOWN\n **'

In [7]: from email import policy
In [8]: message = email.message_from_string(message_text, policy=policy.HTTP)
In [9]: message.get('Subject')
Out[9]: '** ACKNOWLEDGEMENT Host Alert: archerc7.bcn.int.pdp7.net is DOWN **'

Yeah, there's a bundled policy that does what I need, but I think it's not very 
intuitive.

I get that the stdlib is deliberately low level in these parts, and it's more 
of building block to create higher level libraries on top of that, but still I 
feel that getting an email's subject in a friendly fashion should be easy and 
intuitive in the stdlib, or the stdlib's docs should point out clearly to go 
and look for a higher level library because email is hard.

OTOH, working with mail sucks and should be discouraged, so if you want to 
close this definitely I won't complain.

--
status: closed -> open

___
Python tracker 
<https://bugs.python.org/issue34954>
___
___
Python-bugs-list mailing list
Unsubscribe: 
https://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com



[issue34954] Getting an email's subject is error-prone

2018-10-10 Thread R. David Murray


R. David Murray  added the comment:

Use the new email policies in python3.  It handles all the decoding for you.  
I'm afraid you are on your own for python2.

--
resolution:  -> out of date
stage:  -> resolved
status: open -> closed

___
Python tracker 

___
___
Python-bugs-list mailing list
Unsubscribe: 
https://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com



[issue34954] Getting an email's subject is error-prone

2018-10-10 Thread Karthikeyan Singaravelan


Change by Karthikeyan Singaravelan :


--
nosy: +xtreak

___
Python tracker 

___
___
Python-bugs-list mailing list
Unsubscribe: 
https://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com



[issue34954] Getting an email's subject is error-prone

2018-10-10 Thread Alex Corcoles

New submission from Alex Corcoles :

Hi,

This is something that has hit us a few times, as we write a significant 
quantity of software which parses email messages.

The thing is, we use email.header.decode_header to decode the Subject: header 
and it is pretty common for headers to be word-wrapped. If they are, 
decode_header will return a string with newlines in it.

This is something which is unexpected for many people, and can cause bugs which 
are very difficult to detect in code review or testing, as it's easy to not 
trigger wordwrapping if not done deliberately.

We would humbly suggest to provide a friendly way to get an email's subject in 
the expected fashion (i.e. with no newlines) or point out this caveat in the 
docs (or maybe change decode_header to remove newlines itself).

Kind regards,

Álex

--
components: email
messages: 327481
nosy: Alex Corcoles, barry, r.david.murray
priority: normal
severity: normal
status: open
title: Getting an email's subject is error-prone
type: behavior
versions: Python 2.7, Python 3.4, Python 3.5, Python 3.6, Python 3.7, Python 3.8

___
Python tracker 
<https://bugs.python.org/issue34954>
___
___
Python-bugs-list mailing list
Unsubscribe: 
https://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com



[no subject]

2018-09-16 Thread Ajay Patel


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


[no subject]

2018-09-13 Thread V Dota2
>From vigan
Hi i wold like to join in this list because i want to start programing with
python pls acept this
-- 
https://mail.python.org/mailman/listinfo/python-list


[issue34220] Serialization of email message without header line length limit and a non-ASCII subject fails with TypeError

2018-07-25 Thread Grigory Statsenko

New submission from Grigory Statsenko :

I have the following code that creates a simple email message with a) a 
pure-ASCII subject, b) non-ASCII subject
(I made it into a unittest):


import email.generator
import email.policy
from email.mime.multipart import MIMEMultipart
from email.mime.text import MIMEText
from unittest import TestCase


def create_message(subject, sender, recipients, body):
msg = MIMEMultipart()
msg.set_charset('utf-8')
msg.policy = email.policy.SMTP
msg.attach(MIMEText(body, 'html'))
msg['Subject'] = subject
msg['From'] = sender
msg['To'] = ';'.join(recipients)
return msg

class TestEmailMessage(TestCase):
def _make_message(self, subject):
return create_message(
subject=subject, sender='m...@site.com',
recipients=['m...@site.com'], body='Some text',
)

def test_ascii_message_no_len_limit(self):
# very long subject consisting of a single word
subject = 'Q' * 100
msg = self._make_message(subject)
self.assertTrue(str(msg))

def test_non_ascii_message_no_len_limit(self):
# very long subject consisting of a single word
subject = 'Ц' * 100
msg = self._make_message(subject)
self.assertTrue(str(msg))


The ASCII one passes, while the non-ASCII version fails with the following 
exception:

Traceback (most recent call last):
  File "/home/grigory/.pyenv/versions/3.6.4/lib/python3.6/unittest/case.py", 
line 59, in testPartExecutor
yield
  File "/home/grigory/.pyenv/versions/3.6.4/lib/python3.6/unittest/case.py", 
line 605, in run
testMethod()
  File "/home/grigory/PycharmProjects/smtptest/test_message.py", line 36, in 
test_non_ascii_message_no_len_limit
self.assertTrue(str(msg))
  File "/home/grigory/.pyenv/versions/3.6.4/lib/python3.6/email/message.py", 
line 135, in __str__
return self.as_string()
  File "/home/grigory/.pyenv/versions/3.6.4/lib/python3.6/email/message.py", 
line 158, in as_string
g.flatten(self, unixfrom=unixfrom)
  File "/home/grigory/.pyenv/versions/3.6.4/lib/python3.6/email/generator.py", 
line 116, in flatten
self._write(msg)
  File "/home/grigory/.pyenv/versions/3.6.4/lib/python3.6/email/generator.py", 
line 195, in _write
self._write_headers(msg)
  File "/home/grigory/.pyenv/versions/3.6.4/lib/python3.6/email/generator.py", 
line 222, in _write_headers
self.write(self.policy.fold(h, v))
  File "/home/grigory/.pyenv/versions/3.6.4/lib/python3.6/email/policy.py", 
line 183, in fold
return self._fold(name, value, refold_binary=True)
  File "/home/grigory/.pyenv/versions/3.6.4/lib/python3.6/email/policy.py", 
line 205, in _fold
return value.fold(policy=self)
  File 
"/home/grigory/.pyenv/versions/3.6.4/lib/python3.6/email/headerregistry.py", 
line 258, in fold
return header.fold(policy=policy)
  File 
"/home/grigory/.pyenv/versions/3.6.4/lib/python3.6/email/_header_value_parser.py",
 line 144, in fold
return _refold_parse_tree(self, policy=policy)
  File 
"/home/grigory/.pyenv/versions/3.6.4/lib/python3.6/email/_header_value_parser.py",
 line 2645, in _refold_parse_tree
part.ew_combine_allowed, charset)
  File 
"/home/grigory/.pyenv/versions/3.6.4/lib/python3.6/email/_header_value_parser.py",
 line 2722, in _fold_as_ew
first_part = to_encode[:text_space]
TypeError: slice indices must be integers or None or have an __index__ method


The problem is that _fold_as_ew treats maxlen as an integer, but it can also 
have inf and None as valid values. In my case it's inf, but None can also get 
there if the HTTP email policy is used and its max_line_length value is not 
overridden when serializing.
I am supposing that the correct behavior in both of these cases should be no 
wrapping at all. And/or maybe one of these (inf & None) should be converted to 
the other at some point, so only one special case has to handled in the 
low-level code

This behavior is new in Python 3.6. It works in 3.5.
Also fails in 3.7 and 3.8

--
components: email
messages: 322348
nosy: altvod, barry, r.david.murray
priority: normal
severity: normal
status: open
title: Serialization of email message without header line length limit and a 
non-ASCII subject fails with TypeError
type: behavior
versions: Python 3.6, Python 3.7, Python 3.8

___
Python tracker 
<https://bugs.python.org/issue34220>
___
___
Python-bugs-list mailing list
Unsubscribe: 
https://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com



[issue34220] Serialization of email message without header line length limit and a non-ASCII subject fails with TypeError

2018-07-25 Thread R. David Murray


R. David Murray  added the comment:

Thanks for the report.  This is a duplicate of #33524.

--
resolution:  -> duplicate
stage:  -> resolved
status: open -> closed
superseder:  -> non-ascii characters in headers causes TypeError on 
email.policy.Policy.fold

___
Python tracker 

___
___
Python-bugs-list mailing list
Unsubscribe: 
https://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com



[issue34220] Serialization of email message without header line length limit and a non-ASCII subject fails with TypeError

2018-07-25 Thread Karthikeyan Singaravelan

Karthikeyan Singaravelan  added the comment:

I took all the commits made to Lib/email from 3.5 to latest of 3.6 branch with 
`git log --oneline --format="%h" upstream/3.5..upstream/3.6 Lib/email > 
commits.txt`

I could see the test fails with a87ba60 and passes with d94ef8f. Probably 
something to do with a87ba60fe56ae2ebe80ab9ada6d280a6a1f3d552 that had a 
rewrite the email header folding algorithm as I can see from the issue 
https://bugs.python.org/issue27240

cpython git:(master) ✗ ./python
Python 3.8.0a0 (heads/bpo34193-dirty:bfdde5a, Jul 25 2018, 07:51:50)
[GCC 5.4.0 20160609] on linux
Type "help", "copyright", "credits" or "license" for more information.
>>>

# commit a87ba60

cpython git:(master) $ git checkout a87ba60 Lib/email && ./python -m unittest 
bpo34220.py && git reset --quiet HEAD . && git checkout .
.E
==
ERROR: test_non_ascii_message_no_len_limit (bpo34220.TestEmailMessage)
--
Traceback (most recent call last):
  File "/home/cpython/bpo34220.py", line 35, in 
test_non_ascii_message_no_len_limit
self.assertTrue(str(msg))
  File "/home/cpython/Lib/email/message.py", line 135, in __str__
return self.as_string()
  File "/home/cpython/Lib/email/message.py", line 158, in as_string
g.flatten(self, unixfrom=unixfrom)
  File "/home/cpython/Lib/email/generator.py", line 116, in flatten
self._write(msg)
  File "/home/cpython/Lib/email/generator.py", line 195, in _write
self._write_headers(msg)
  File "/home/cpython/Lib/email/generator.py", line 222, in _write_headers
self.write(self.policy.fold(h, v))
  File "/home/cpython/Lib/email/policy.py", line 183, in fold
return self._fold(name, value, refold_binary=True)
  File "/home/cpython/Lib/email/policy.py", line 205, in _fold
return value.fold(policy=self)
  File "/home/cpython/Lib/email/headerregistry.py", line 258, in fold
return header.fold(policy=policy)
  File "/home/cpython/Lib/email/_header_value_parser.py", line 144, in fold
return _refold_parse_tree(self, policy=policy)
  File "/home/cpython/Lib/email/_header_value_parser.py", line 2645, in 
_refold_parse_tree
part.ew_combine_allowed, charset)
  File "/home/cpython/Lib/email/_header_value_parser.py", line 2722, in 
_fold_as_ew
first_part = to_encode[:text_space]
TypeError: slice indices must be integers or None or have an __index__ method

--
Ran 2 tests in 0.022s

FAILED (errors=1)

# commit d94ef8f
  
cpython git:(master) $ git checkout d94ef8f Lib/email && ./python -m unittest 
bpo34220.py && git reset --quiet HEAD . && git checkout .
..
--
Ran 2 tests in 0.017s

OK


Hope I am correct on the above approach and there are no C code related changes 
that need to be made to recompile Python.

Thanks

--

___
Python tracker 

___
___
Python-bugs-list mailing list
Unsubscribe: 
https://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com



[issue34220] Serialization of email message without header line length limit and a non-ASCII subject fails with TypeError

2018-07-25 Thread Karthikeyan Singaravelan


Change by Karthikeyan Singaravelan :


--
nosy: +xtreak

___
Python tracker 

___
___
Python-bugs-list mailing list
Unsubscribe: 
https://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com



[issue33971] os.mknod is subject to "umask"

2018-06-26 Thread James Stevens


New submission from James Stevens :

As per the underlying "libc" call, the node created with "mknod" is subjected 
to the user's current umask setting.

This is not made clear in the Python documentation, but the "libc" 
documentation makes this clear (see attached).

--
assignee: docs@python
components: Documentation
files: Selection_2018-06-26_003.png
messages: 320490
nosy: docs@python, james_r_c_stevens
priority: normal
severity: normal
status: open
title: os.mknod is subject to "umask"
versions: Python 3.6
Added file: https://bugs.python.org/file47653/Selection_2018-06-26_003.png

___
Python tracker 
<https://bugs.python.org/issue33971>
___
___
Python-bugs-list mailing list
Unsubscribe: 
https://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com



Re: (no subject)

2018-06-10 Thread Rick Johnson
sagar daya wrote:
> Couldn't install any module from pip
> Plz help???

As with most actions, an algorithm is required. (shocking, i
know!)

What methodology have you implemented thus far to achieve
your goal of "installing modules from PIP"? Please enumerate
the steps you chose to take, and then we _might_ can offer
advice.

For instance, if someone is having trouble brushing their
teeth, the first question we might ask is: "Have you located
the toothbrush and toothpaste yet?". 

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


[no subject]

2018-06-10 Thread sagar daya
Couldn't install any module from pip
Plz help???
-- 
https://mail.python.org/mailman/listinfo/python-list


[issue25257] In subject line email library inserts unwanted space after a thousands comma in a number

2018-03-27 Thread Bob Hossley

Bob Hossley <bhoss...@ieee.org> added the comment:

Mike,

Thank you.

I moved to Python 3 some time ago.  I confirm that Python 3 does not
have the problem.  But I can't conveniently verify your workaround for
Python 2.

Regards,
Bob
bhoss...@ieee.org

On 2018-03-27 11:30 AM, Mike Edmunds wrote:
> 
> Mike Edmunds <medmu...@gmail.com> added the comment:
> 
> Here's a workaround for Python 2.7:
> 
> ```
> class HeaderBugWorkaround(email.header.Header):
> def encode(self, splitchars=' ', **kwargs):  # only split on spaces, 
> rather than splitchars=';, '
> return email.header.Header.encode(self, splitchars, **kwargs)
> 
> # and then...
> 
> msg['Subject'] = HeaderBugWorkaround(subject, 'utf-8', header_name='Subject')
> 
> ```
> 
> (If you have the option, you're almost certainly better off moving to Python 
> 3 for anything email related. But if you're maintaining code that has to be 
> Python 2.7 compatible, this might help.)
> 
> --
> nosy: +medmunds
> 
> ___
> Python tracker <rep...@bugs.python.org>
> <https://bugs.python.org/issue25257>
> ___
>

--

___
Python tracker <rep...@bugs.python.org>
<https://bugs.python.org/issue25257>
___
___
Python-bugs-list mailing list
Unsubscribe: 
https://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com



[issue25257] In subject line email library inserts unwanted space after a thousands comma in a number

2018-03-27 Thread Mike Edmunds

Mike Edmunds <medmu...@gmail.com> added the comment:

Here's a workaround for Python 2.7:

```
class HeaderBugWorkaround(email.header.Header):
def encode(self, splitchars=' ', **kwargs):  # only split on spaces, rather 
than splitchars=';, '
return email.header.Header.encode(self, splitchars, **kwargs)

# and then...

msg['Subject'] = HeaderBugWorkaround(subject, 'utf-8', header_name='Subject')

```

(If you have the option, you're almost certainly better off moving to Python 3 
for anything email related. But if you're maintaining code that has to be 
Python 2.7 compatible, this might help.)

--
nosy: +medmunds

___
Python tracker <rep...@bugs.python.org>
<https://bugs.python.org/issue25257>
___
___
Python-bugs-list mailing list
Unsubscribe: 
https://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com



Re: (no subject)

2018-03-27 Thread Rick Johnson
On Tuesday, March 27, 2018 at 7:19:53 AM UTC-5, kevon harris wrote:
> Unable to pull up IDLE after downloading Python 3.6.4
> 
> Sent from Mail for Windows 10

What OS?

On Windows running Python2.X, IDLE is located @ '/Python2X/Lib/idlelib/idle.pyw'
-- 
https://mail.python.org/mailman/listinfo/python-list


[no subject]

2018-03-27 Thread kevon harris
Unable to pull up IDLE after downloading Python 3.6.4

Sent from Mail for Windows 10

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


[issue32058] Faulty behaviour in email.utils.parseaddr if square brackets in subject

2017-11-17 Thread R. David Murray

R. David Murray  added the comment:

Unfortunately the imap module in the stdlib doesn't provide a whole lot in the 
way of tools for parsing the imap data, just for sending it back and forth to 
the server.

--

___
Python tracker 

___
___
Python-bugs-list mailing list
Unsubscribe: 
https://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com



[issue32058] Faulty behaviour in email.utils.parseaddr if square brackets in subject

2017-11-17 Thread tom de wulf

tom de wulf <dewulfm...@gmail.com> added the comment:

I do get this data from an IMAP fetch statement, see my code below:

rv, data = imap.fetch(num, "(BODY[HEADER.FIELDS (FROM SUBJECT)])")
if rv != 'OK':
logging.error("Error getting message sender and subject (" + 
num.decode("ascii") + ")")
return
logging.info("Got message " + num.decode("ascii"))

sender_subject = data[0][1].decode("utf-8")
sender = email.utils.parseaddr(sender_subject.replace('[', 
'').replace(']',''))[1].replace("\r\n", "")

Thank you for providing this new API though, I will make sure to switch to that.

--

___
Python tracker <rep...@bugs.python.org>
<https://bugs.python.org/issue32058>
___
___
Python-bugs-list mailing list
Unsubscribe: 
https://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com



[issue32058] Faulty behaviour in email.utils.parseaddr if square brackets in subject

2017-11-17 Thread R. David Murray

R. David Murray  added the comment:

parseaddr is for parsing the contents of an address header, not for parsing any 
additional text.  So the correct way to call it is parseaddress('someone 
').

In any case, please look in to the new email policies, which provide a much 
more convenient API:

>>> from email import message_from_bytes
>>> from email.policy import default
>>> m = message_from_bytes(b'Subject: I am a bug [Random]\r\nFrom: someone 
\r\n\r\n', policy=default)
>>> m['from']
'someone '
>>> m['from'].addresses
(Address(display_name='someone', username='some', domain='email.address'),)
>>> m['from'].addresses[0].display_name
'someone'
>>> m['from'].addresses[0].username
'some'
>>> m['from'].addresses[0].addr_spec
'some@email.address'

--
resolution:  -> not a bug
stage:  -> resolved
status: open -> closed

___
Python tracker 

___
___
Python-bugs-list mailing list
Unsubscribe: 
https://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com



[issue32058] Faulty behaviour in email.utils.parseaddr if square brackets in subject

2017-11-17 Thread tom de wulf

New submission from tom de wulf <dewulfm...@gmail.com>:

Probably a parsing bug in email.utils.parseaddr.

How to recreate:

>>> import email.utils
>>> test = 'Subject: I am a bug [Random]\r\nFrom: someone 
>>> <some@email.address>\r\n\r\n'
>>> email.utils.parseaddr(test)
('', 'I')
>>> email.utils.parseaddr(test.replace('[', '').replace(']',''))
('someone', 'some@email.address')

Expected behaviour: no need to remove the []'s

--
components: email
messages: 306431
nosy: barry, r.david.murray, tom de wulf
priority: normal
severity: normal
status: open
title: Faulty behaviour in email.utils.parseaddr if square brackets in subject
type: behavior
versions: Python 3.5

___
Python tracker <rep...@bugs.python.org>
<https://bugs.python.org/issue32058>
___
___
Python-bugs-list mailing list
Unsubscribe: 
https://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com



Re: python list name in subject

2017-08-22 Thread Abdur-Rahmaan Janhangeer
ah thanks for the tip about me filtering them

thought the community liked core python style (mail lists where python dev
talk, discuss ideas,i.e. the ones where guido replies etc)

anyways thanks all

Abdur-Rahmaan Janhangeer,
Mauritius
abdurrahmaanjanhangeer.wordpress.com

On 22 Aug 2017 12:38, "Abdur-Rahmaan Janhangeer" <arj.pyt...@gmail.com>
wrote:

> Hi all,
>
> i am subscribed to different python lists and they put their names in the
> subject
> [name] subject
>
> hence i can at a glance tell which mail belongs to which list.
>
> A requests to admins to implement if possible
>
> Thank you!
>
>
> <https://www.avast.com/sig-email?utm_medium=email_source=link_campaign=sig-email_content=webmail>
>  Garanti
> sans virus. www.avast.com
> <https://www.avast.com/sig-email?utm_medium=email_source=link_campaign=sig-email_content=webmail>
> <#m_1748413376357339298_DAB4FAD8-2DD7-40BB-A1B8-4E2AA1F9FDF2>
>
-- 
https://mail.python.org/mailman/listinfo/python-list


Re: python list name in subject

2017-08-22 Thread Ben Finney
Abdur-Rahmaan Janhangeer <arj.pyt...@gmail.com> writes:

> i am subscribed to different python lists and they put their names in the
> subject
> [name] subject

That's non-standard. The standard place for that information is the
“List-Id” field <URL:https://tools.ietf.org/html/rfc2919>.

> hence i can at a glance tell which mail belongs to which list.

Set up a filter on the specific value of the “List-Id” field, which is
set by any standards-conformant mailing list software.

Presto, you get any organisation you like based on that information; and
the rest of us don't get the Subject field cluttered.

-- 
 \   “Most people are other people. Their thoughts are someone |
  `\  else’s opinions, their lives a mimicry, their passions a |
_o__)   quotation.” —Oscar Wilde, _De Profundis_, 1897 |
Ben Finney

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


Re: python list name in subject

2017-08-22 Thread Grant Edwards
On 2017-08-23, D'Arcy Cain <da...@vybenetworks.com> wrote:
> On 08/22/2017 10:14 AM, Grant Edwards wrote:
>> Please don't. It wastes space which is better used on the subject.  If
>> you want the mailing list prepended, then configure procmail (or
>> whatever) to do it for you.
>
> Better yet, put it in its own folder.

Even better, point a news client[1] at

   nntp://news.gmane.org/gmane.comp.python.general


[1] https://en.wikipedia.org/wiki/List_of_Usenet_newsreaders

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


Re: python list name in subject

2017-08-22 Thread D'Arcy Cain

On 08/22/2017 10:14 AM, Grant Edwards wrote:

Please don't. It wastes space which is better used on the subject.  If
you want the mailing list prepended, then configure procmail (or
whatever) to do it for you.


Better yet, put it in its own folder.

--
D'Arcy J.M. Cain
Vybe Networks Inc.
http://www.VybeNetworks.com/
IM:da...@vex.net VoIP: sip:da...@vybenetworks.com
--
https://mail.python.org/mailman/listinfo/python-list


Re: python list name in subject

2017-08-22 Thread Rick Johnson
Tim Chase wrote:
> Rick Johnson wrote:

[...]

> Checking mailing list headers...yep, the "forum-of-origin"
> type hint is already present in standards-compliant fashion
> defined by RFC4021[1]:
>
> [...]
> 
> Just need a mail client that knows about standards and
> isn't fettered. ;-)

Well, that pretty much disqualifies google groups. :-)
-- 
https://mail.python.org/mailman/listinfo/python-list


Re: python list name in subject

2017-08-22 Thread Tim Chase
On 2017-08-22 08:21, Rick Johnson wrote:
> Grant Edwards wrote:
> > Abdur-Rahmaan Janhangeer wrote:  
> > > 
> > > Hi all,  i am subscribed to different python lists and
> > > they put their names in the subject [name] subject  hence
> > > i can at a glance tell which mail belongs to which list.
> > > A requests to admins to implement if possible  
> > 
> > Please don't. It wastes space which is better used on the
> > subject.  If you want the mailing list prepended, then
> > configure procmail (or whatever) to do it for you.  
> 
> Although, considering that the BDFL has now made type-hints
> an official part of the language, a "forum-of-origin" type-
> hint, may be more Pythonic than we care to realize. 

Checking mailing list headers...yep, the "forum-of-origin" type hint
is already present in standards-compliant fashion defined by
RFC4021[1]:

List-Id: General discussion list for the Python programming language
 
List-Unsubscribe: <https://mail.python.org/mailman/options/python-list>,
 <mailto:python-list-requ...@python.org?subject=unsubscribe>
List-Archive: <http://mail.python.org/pipermail/python-list/>
List-Post: <mailto:python-list@python.org>
List-Help: <mailto:python-list-requ...@python.org?subject=help>
List-Subscribe: <https://mail.python.org/mailman/listinfo/python-list>,
 <mailto:python-list-requ...@python.org?subject=subscribe>

Just need a mail client that knows about standards and isn't
fettered. ;-)

-tkc


[1] https://tools.ietf.org/html/rfc4021#section-2.1.31
-- 
https://mail.python.org/mailman/listinfo/python-list


Re: python list name in subject

2017-08-22 Thread Rick Johnson
Grant Edwards wrote:
> Abdur-Rahmaan Janhangeer wrote:
> > 
> > Hi all,  i am subscribed to different python lists and
> > they put their names in the subject [name] subject  hence
> > i can at a glance tell which mail belongs to which list.
> > A requests to admins to implement if possible
> 
> Please don't. It wastes space which is better used on the
> subject.  If you want the mailing list prepended, then
> configure procmail (or whatever) to do it for you.

Although, considering that the BDFL has now made type-hints
an official part of the language, a "forum-of-origin" type-
hint, may be more Pythonic than we care to realize. 

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


Re: python list name in subject

2017-08-22 Thread Grant Edwards
On 2017-08-22, Abdur-Rahmaan Janhangeer <arj.pyt...@gmail.com> wrote:
> Hi all,
>
> i am subscribed to different python lists and they put their names in the
> subject
> [name] subject
>
> hence i can at a glance tell which mail belongs to which list.
>
> A requests to admins to implement if possible

Please don't. It wastes space which is better used on the subject.  If
you want the mailing list prepended, then configure procmail (or
whatever) to do it for you.

-- 
Grant Edwards   grant.b.edwardsYow! Hey, waiter!  I want
  at   a NEW SHIRT and a PONY TAIL
  gmail.comwith lemon sauce!

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


  1   2   3   4   5   6   >