Re: Issue with opening a python file

[Steven D'Aprano]

On Fri, 1 Apr 2016 02:56 pm, Daniel Ding wrote:

> Hello, I'm relatively new to python.
> Recently I have been receiving errors every time I attempt to open python
> files. When try open them, it sends me directly to the 'Modify Setup'
> window. Clicking on repair or modify does not fix the problem, it simply
> goes through the repair or modify process and then closes, whilst the
> problem still persists.  Is there any possible fix for this?

Depends. What has changed? Have you upgrade the OS? (Windows 8 apparently
tends to auto-update to Windows 10 without warning.) Installed a new
version of Python which doesn't work?

What happens if you try to launch the Python application directly, without a
file? Open a shell (command.exe or cmd.com or whatever Windows calls it)
and try entering "python" or "python3". What happens?

If you get an error message, try to copy and paste the complete error
message into your reply. Otherwise try to type out the actual error
message.

Don't bother taking a screen-shot unless the message is extremely large:
firstly, this mailing list and newsgroup will delete attachments, so you
would have to post it to imgur or similar, and secondly, a screen-shot is
of no use to anyone using a screen reader.



-- 
Steven

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

Set type for datetime intervals

[Nagy László Zsolt]

 
  Hello,

I need to compare sets of datetime intervals, and make set operations on
them: intersect, union, difference etc. One element of a set would be an
interval like this:

element ::= (start_point_in_time, end_point_in_time)
intervalset ::= { element1, element2,  }

Operations on elements:

element1.intersect(element2)
element1.union(element2)
element1.minus(element2)

Operations on sets:

intervalset1.intersect(intervalset2)
intervalset1.union(intervalset2)
intervalset1.minus(intervalset2)

Does anyone know a library that already implements these functions?

Thanks,

  Laszlo


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

Re: Threading is foobared?

[Mark Sapiro]

Random832 wrote:

> One additional thing that would be nice and would solve most of the
> duplicate problem with hypothetically including the rewritten
> Message-IDs in outgoing emails, would be to detect crossposts to
> multiple lists in the same Mailman instance, and to send them to Usenet
> (and to subscribers) as a single message, with appropriate headers for a
> crosspost.


This is difficult to do for various reasons. The main issue is gating to
news is asynchronously done by a separate process. Even if the process
could reliably determine that another gatewayed list in the installation
was a recipient of this post which it could only do by examining
explicit addressees and the other list might be a Bcc:, we'd still have
to arbitrate somehow which post gets gatewayed to the multiple news
groups and which ones get dropped. Although I suppose we could send each
one for all the news groups and let the news server figure it out.

Anyway, I don't plan to try this.

-- 
Mark Sapiro The highway is for gamblers,
San Francisco Bay Area, Californiabetter use your sense - B. Dylan
-- 
https://mail.python.org/mailman/listinfo/python-list

Re: Threading is foobared?

[Mark Sapiro]

Random832 wrote:

> Any chance that it could fix reference headers to match?
> 
> Actually, merely prepending the original Message-ID itself to the
> references header might be enough to change the reply's situation from
> "nephew" ("reply to [missing] sibling") to "grandchild" ("reply to
> [missing] reply"), which might be good enough to make threading work
> right on most clients, and would be *easy* (whereas maintaining an
> ongoing reversible mapping may not be).
> 
> And if it's not too much additional work, maybe throw in an
> X-Mailman-Original-Message-ID (and -References if anything is done with
> that) field, so that the original state can be recovered.


I think these are good ideas. I'm going to try to do something along
these lines.


> Rather than exclusively rewriting for usenet, maybe the rewritten
> headers could also be included in outgoing emails and the archive?
> 
> Putting it in outgoing emails would solve the problem entirely, though
> it would mean people get duplicates if they're subscribed to multiple
> lists to which something is posted or get CC'd. The archive wouldn't
> have this issue.


This is more difficult since archiving, gatewaying to Usenet and
delivery to list members are asynchronous processes that have no way to
communicate with each other.

It could be accomplished by doing a Usenet check in the incoming
pipeline and putting the Mailman Message-ID in the message metadata or
doing the mods at that point, but I don't think I want to expand the
scope of something that is non RFC compliant in the first place.

I need to think about these things some more.

-- 
Mark Sapiro The highway is for gamblers,
San Francisco Bay Area, Californiabetter use your sense - B. Dylan
-- 
https://mail.python.org/mailman/listinfo/python-list

Issue with opening a python file

[Daniel Ding]

Hello, I'm relatively new to python.
Recently I have been receiving errors every time I attempt to open python 
files. When try open them, it sends me directly to the 'Modify Setup' window. 
Clicking on repair or modify does not fix the problem, it simply goes through 
the repair or modify process and then closes, whilst the problem still 
persists.  Is there any possible fix for this?

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

The next major Python version will be Python 8

[Victor Stinner]

Hi,

Python 3 becomes more and more popular and is close to a dangerous point
where it can become popular that Python 2. The PSF decided that it's
time to elaborate a new secret plan to ensure that Python users suffer
again with a new major release breaking all their legacy code.

The PSF is happy to announce that the new Python release will be
Python 8!

Why the version 8? It's just to be greater than Perl 6 and PHP 7, but
it's also a mnemonic for PEP 8. By the way, each minor release will now
multiply the version by 2. With Python 8 released in 2016 and one
release every two years, we will beat Firefox 44 in 2022 (Python 64) and
Windows 2003 in 2032 (Python 2048).

A major release requires a major change to justify a version bump: the
new killer feature is that it's no longer possible to import a module
which does not respect the PEP 8. It ensures that all your code is pure.
Example:

$ python8 -c 'import keyword'
Lib/keyword.py:16:1: E122 continuation line missing indentation or outdented
Lib/keyword.py:16:1: E265 block comment should start with '# '
Lib/keyword.py:50:1: E122 continuation line missing indentation or outdented
(...)
ImportError: no pep8, no glory

Good news: since *no* module of the current standard library of Python 3
respect the PEP 8, the standard library will be simplified to one
unique module, which is new in Python 8: pep8. The standard library will
move to the Python Cheeseshop (PyPI), to reply to an old and popular
request.


DON'T PANIC! You are still able to import your legacy code into
Python 8, you just have to rename all your modules to add a "_noqa" suffix
to the filename. For example, rename utils.py to utils_noqa.py. A side
effect is that you have to update all imports. For example, replace
"import django" with "import django_noqa". After a study of the PSF,
it's a best option to split again the Python community and make sure
that all users are angry.


The plan is that in 10 years, at least 50% of the 77,000 packages on the
Python cheeseshop will be updated to get the "_noqa" tag. After 2020,
the PSF will start to sponsor trolls to harass users of the legacy
Python 3 to force them to migrate to Python 8.


Python 8 is a work-in-progress (it's still an alpha version), the
standard library was not removed yet. Hopefully, trying to import any
module of the standard library fails.

Don't hesitate to propose more ideas to make Python 8 more incompatible
with Python 3!

Note: The change is already effective in the default branch of Python:
https://hg.python.org/cpython/rev/9aedec2dbc01

Have fun,
Victor
-- 
https://mail.python.org/mailman/listinfo/python-announce-list

Support the Python Software Foundation:
http://www.python.org/psf/donations/

[issue26683] Questionable terminology for describing what locals() does

[Raymond Hettinger]

Raymond Hettinger added the comment:

> A national variable maybe :)

I would think that "nonlocal" is exactly the right term given that that is how 
you would declare it if you wanted to write to it.

>>> w = 5

>>> def f(x):
def g(y):
nonlocal x
global w
z = x + y
x += 1
print(locals())
print(globals())
return g

>>> f(10)(20)
{'y': 20, 'x': 11, 'z': 30}
{'w': 5, ...}

--

___
Python tracker 

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

[issue26680] Incorporating float.is_integer into the numeric tower and Decimal

[Serhiy Storchaka]

Serhiy Storchaka added the comment:

Agree with Raymond.

float.is_integer(x) is more efficient than x==int(x), but is this method used 
anywhere at all? It was added as a part of issue2224.

--
nosy: +christian.heimes, serhiy.storchaka

___
Python tracker 

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

[issue26684] pathlib.Path.with_name() and .with_suffix do not allow combining with an empty Path

[Serhiy Storchaka]

Serhiy Storchaka added the comment:

There is no a bug. This is the documented and reasonable behavior. What 
behavior you expect?

--
nosy: +serhiy.storchaka

___
Python tracker 

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

Re: Use pyodbc to count and list tables, columns, indexes, etc

[DFS]

On 3/31/2016 11:44 PM, DFS wrote:


import pyodbc

dbName = "D:\test_data.mdb"
conn = pyodbc.connect('DRIVER={Microsoft Access Driver
(*.mdb)};DBQ='+dbName)
cursor = conn.cursor()

#COUNT TABLES, LIST COLUMNS
tblCount = 0
for rows in cursor.tables():
 if rows.table_type == "TABLE":  #LOCAL TABLES ONLY
 tblCount += 1
 print rows.table_name
 for fld in cursor.columns(rows.table_name):
 print(fld.table_name, fld.column_name)

print tblCount,"tables"


Problem is, the 'for rows' loop executes only once if the 'for fld' loop
is in place.  So even if I have 50 tables, the output is like:

DATA_TYPES
(u'DATA_TYPES', u'FLD_TEXT', -9, u'VARCHAR')
(u'DATA_TYPES', u'FLD_MEMO', -10, u'LONGCHAR')
(u'DATA_TYPES', u'FLD_NBR_BYTE', -6, u'BYTE')
1 tables

And no errors are thrown.

If I comment out the 2 'for fld' lines, it counts and lists all 50
tables correctly.

Any ideas?

Thanks!



Never mind!  I discovered I just needed a 2nd cursor object for the columns.

---
 cursor1 = conn.cursor()
 cursor2 = conn.cursor()

 tblCount = 0
 for rows in cursor1.tables():
  if rows.table_type == "TABLE":
  tblCount += 1
  print rows.table_name
  for fld in cursor2.columns(rows.table_name):
  print(fld.table_name, fld.column_name)
---

Works splendiferously.


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

[issue26682] Ttk Notebook tabs do not show with 1-2 char names

[Serhiy Storchaka]

Serhiy Storchaka added the comment:

I see the names of the first 4 tabs: 0-3. Tab header for the last tab is empty. 
If use longer name (e.g. "45678") I see it without two last characters ("456").

Yes, it looks as Ttk bug. Have you reported this to the mainstream?

--

___
Python tracker 

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

Re: The next major Python version will be Python 8

[Steven D'Aprano]

On Fri, 1 Apr 2016 11:13 am, Chris Angelico wrote:

> Now's the time to get in with the ideas. My proposal is that Python 8,
> in keeping with its new opinionated style, will require everyone to
> follow a single timezone: Europe/Amsterdam.

Swatch Internet time:

https://en.wikipedia.org/wiki/Swatch_Internet_Time


-- 
Steven

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

Use pyodbc to count and list tables, columns, indexes, etc

[DFS]

import pyodbc

dbName = "D:\test_data.mdb"
conn = pyodbc.connect('DRIVER={Microsoft Access Driver 
(*.mdb)};DBQ='+dbName)

cursor = conn.cursor()

#COUNT TABLES, LIST COLUMNS
tblCount = 0
for rows in cursor.tables():
if rows.table_type == "TABLE":  #LOCAL TABLES ONLY
tblCount += 1
print rows.table_name
for fld in cursor.columns(rows.table_name):
print(fld.table_name, fld.column_name)

print tblCount,"tables"


Problem is, the 'for rows' loop executes only once if the 'for fld' loop 
is in place.  So even if I have 50 tables, the output is like:


DATA_TYPES
(u'DATA_TYPES', u'FLD_TEXT', -9, u'VARCHAR')
(u'DATA_TYPES', u'FLD_MEMO', -10, u'LONGCHAR')
(u'DATA_TYPES', u'FLD_NBR_BYTE', -6, u'BYTE')
1 tables

And no errors are thrown.

If I comment out the 2 'for fld' lines, it counts and lists all 50 
tables correctly.


Any ideas?

Thanks!

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

[issue26683] Questionable terminology for describing what locals() does

[Martin Panter]

Martin Panter added the comment:

Regarding “free variables”, in Issue 17546 I proposed the wording “. . . also 
includes non-local, non-global names”.

In your code example, I would consider y to be 100 percent local to the g() 
function. It is a function parameter, and “y += 1” should work. I agree x is 
not a true local, it is a “non-local non-global”. A national variable maybe :)

For functions, considering that you shouldn’t modify the dictionary (original 
concern in Issue 17546), I do agree the behaviour is a bit strange and 
inconsistent. It might have made more sense to either only return true locals, 
or return a complete namespace of locals, non-locals, globals, and builtins. It 
seems there is no way to get a similar list of non-local non-globals in a class 
scope.

--
nosy: +martin.panter

___
Python tracker 

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

[issue26684] pathlib.Path.with_name() and .with_suffix do not allow combining with an empty Path

[Ethan Furman]

New submission from Ethan Furman:

The methods .with_name() and .with_suffix() of pathlib.Path (and friends) do 
not allow a name or suffix to be added to a path alone -- I get ValueError(... 
has an empty name...).

This is the documented behavior, but it seems incredibly user-unfriendly.

--
messages: 262717
nosy: ethan.furman, pitrou
priority: normal
severity: normal
status: open
title: pathlib.Path.with_name() and .with_suffix do not allow combining with an 
empty Path
type: behavior
versions: Python 3.5, Python 3.6

___
Python tracker 

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

[issue26647] ceval: use Wordcode, 16-bit bytecode

[Demur Rumed]

Changes by Demur Rumed :


Added file: http://bugs.python.org/file42339/wpy3.patch

___
Python tracker 

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

[issue26647] ceval: use Wordcode, 16-bit bytecode

[Demur Rumed]

Changes by Demur Rumed :


Removed file: http://bugs.python.org/file42338/wpy3.patch

___
Python tracker 

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

[issue26647] ceval: use Wordcode, 16-bit bytecode

[Demur Rumed]

Demur Rumed added the comment:

Addressed feedback from josh.rosenberg besides reintroducing FOURTH/SET_FOURTH

--
Added file: http://bugs.python.org/file42338/wpy3.patch

___
Python tracker 

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

[issue26680] Incorporating float.is_integer into the numeric tower and Decimal

[Raymond Hettinger]

Raymond Hettinger added the comment:

One other thought:  the name is_integer() is inconsistent with the nomenclature 
in numbers.py.  Had this been included at the outset, its name would have been 
is_integral().

--

___
Python tracker 

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

[issue26680] Incorporating float.is_integer into the numeric tower and Decimal

[Raymond Hettinger]

Raymond Hettinger added the comment:

-0 

I question whether we ever needed a short-cut for x==int(x).  Adding this to 
the numeric tower would cause it to propagate broadly including the int type.  
To me, this seems like feature creep resulting in language bloat.  

The decimal module has been around for a long time and no one has ever 
requested the feature.  This suggests it would be just another unused method in 
a module that already has learnability and usability problems due to a fat API.

--

___
Python tracker 

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

[issue26683] Questionable terminology for describing what locals() does

[Raymond Hettinger]

New submission from Raymond Hettinger:

The docs for locals() say that inside a function that local variables and free 
variables are included:  https://docs.python.org/3/library/functions.html#locals

Elsewhere we use the terms "cell variables" or "nonlocals".   Mathematically, 
the word "free" means unbound, so that isn't applicable here and isn't the 
usual way of describing variables in the enclosing scope.

>>> def f(x):
def g(y):
z = x + y
print(locals())
return g

>>> f(10)(20)
{'x': 10, 'y': 20, 'z': 30}

Also, I'm not sure why "x" and "y" are included in the definition for locals(). 
 That seems strange given that "x" and "y" are not local to "g" and that "x += 
1" would fail with an UnboundLocalError.

--
assignee: docs@python
components: Documentation
messages: 262713
nosy: docs@python, rhettinger
priority: normal
severity: normal
status: open
title: Questionable terminology for describing what locals() does
versions: Python 2.7, Python 3.5, Python 3.6

___
Python tracker 

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

[issue26682] Ttk Notebook tabs do not show with 1-2 char names

[Terry J. Reedy]

New submission from Terry J. Reedy:

>From 
>https://stackoverflow.com/questions/36336010/cannot-see-all-tabs-in-ttk-notebook

import tkinter as tk
from tkinter.ttk import Frame, Notebook

root = tk.Tk()
nb = Notebook(root, width=320, height=240)
nb.pack(fill='both', expand=1)
page0 = Frame(nb)
page1 = Frame(nb)
page2 = Frame(nb)
page3 = Frame(nb)
page4 = Frame(nb)
nb.add(page0, text="0")
nb.add(page1, text="1")
nb.add(page2, text="2")
nb.add(page3, text="3")
nb.add(page4, text="4")

Only tabs 0 and 1 show.  Add a space before or after the number and 2 & 3 show. 
 Add 6 spaces after 4 and '4 ' shows.  Appears to work OK with 3 chars, with 
first and third non-blank.

I presume this is a ttk bug.  
http://www.tcl.tk/man/tcl8.6/TkCmd/ttk_notebook.htm#M14 just says 'a string'.  
I plan to close this as 3rd party in a few days, but I wanted to document the 
defacto spec here on the tracker.

--
components: Tkinter
messages: 262712
nosy: serhiy.storchaka, terry.reedy, wordtech
priority: normal
severity: normal
status: open
title: Ttk Notebook tabs do not show with 1-2 char names
type: behavior
versions: Python 2.7, Python 3.5, Python 3.6

___
Python tracker 

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

Re: The next major Python version will be Python 8

[Roel Schroeven]

Ethan Furman schreef op 2016-04-01 02:09:

On 03/31/2016 05:02 PM, Roel Schroeven wrote:

Victor Stinner schreef op 2016-03-31 23:40:



Python 3 becomes more and more popular and is close to a dangerous point
where it can become popular that Python 2. The PSF decided that it's
time to elaborate a new secret plan to ensure that Python users suffer
again with a new major release breaking all their legacy code.

"2016-03-31 23:40"
You're 20 minutes early :)


No, that's a naive datetime.  You need to travel to Victor's location to 
figure out what that is there.


I'm not sure exactly how this stuff works, but I was under the 
impression that that was a local datetime in Victor's timezone. I might 
very well be wrong about that.



--
The saddest aspect of life right now is that science gathers knowledge
faster than society gathers wisdom.
  -- Isaac Asimov

Roel Schroeven

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

Re: pip.exe issue with 3.5.1

[Irmen de Jong]

On 1-4-2016 0:27, hellofootball1 . wrote:
> So i just downloaded python 3.5.1 on my laptop and my pip.exe was not
> working. It would almost immediately close on me after I clicked on it. So
> i deleted the scripts folder as all of them did the same thing and then
> tried the modify feature and the repair feature of your installer to try
> and get pip back but it has not worked. Would you just recommend that I
> install 3.4.4 and just use that instead?
> 

No. Pip works fine with python 3.5.1. What did you expect to happen?
Pip is not a program that you *click* on, you operate it from the command line 
instead.
Try typing 'pip.exe' on a cmd prompt and go from there.

Irmen

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

Re: The next major Python version will be Python 8

[Chris Angelico]

On Fri, Apr 1, 2016 at 11:09 AM, Ethan Furman  wrote:
> On 03/31/2016 05:02 PM, Roel Schroeven wrote:
>>
>> Victor Stinner schreef op 2016-03-31 23:40:
>
>
>>> Python 3 becomes more and more popular and is close to a dangerous point
>>> where it can become popular that Python 2. The PSF decided that it's
>>> time to elaborate a new secret plan to ensure that Python users suffer
>>> again with a new major release breaking all their legacy code.
>>
>>
>> "2016-03-31 23:40"
>> You're 20 minutes early :)
>
>
> No, that's a naive datetime.  You need to travel to Victor's location to
> figure out what that is there.
>
> I sure hope Python 8 doesn't have that problem!

Now's the time to get in with the ideas. My proposal is that Python 8,
in keeping with its new opinionated style, will require everyone to
follow a single timezone: Europe/Amsterdam.

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

Re: Convert set to list

[Rob Gaddi]

Larry Martell wrote:

> I feel like I've converted sets to lists before. But maybe not. Or
> maybe I am losing it from having worked 70 hours this week.
>
> Shouldn't this work?
>
> (Pdb) print block['relative_chart1']['vessel_names']
> set([u'Common Carotid', u'External Carotid', u'Internal Carotid'])
> (Pdb) type(block['relative_chart1']['vessel_names'])
> 
> (Pdb) list(block['relative_chart1']['vessel_names'])
> *** Error in argument: "(block['relative_chart1']['vessel_names'])"

Pdb takes the "list" command as a request to list source code.

print list(block['relative_chart1']['vessel_names']) should work.

-- 
Rob Gaddi, Highland Technology -- www.highlandtechnology.com
Email address domain is currently out of order.  See above to fix.
-- 
https://mail.python.org/mailman/listinfo/python-list

Re: The next major Python version will be Python 8

[D'Arcy J.M. Cain]

On Fri, 01 Apr 2016 02:02:34 +0200
Roel Schroeven  wrote:
> Victor Stinner schreef op 2016-03-31 23:40:
> > Python 3 becomes more and more popular and is close to a dangerous
> > point where it can become popular that Python 2. The PSF decided
> > that it's time to elaborate a new secret plan to ensure that Python
> > users suffer again with a new major release breaking all their
> > legacy code.
> 
> "2016-03-31 23:40"
> You're 20 minutes early :)

And too obvious.

-- 
D'Arcy J.M. Cain
System Administrator, Vex.Net
http://www.Vex.Net/ IM:da...@vex.net
VoIP: sip:da...@vex.net
-- 
https://mail.python.org/mailman/listinfo/python-list

Re: Convert set to list

[Larry Martell]

On Thursday, March 31, 2016, Ben Finney  wrote:

> Larry Martell > writes:
>
> > I feel like I've converted sets to lists before. But maybe not. Or
> > maybe I am losing it from having worked 70 hours this week.
> >
> > Shouldn't this work?
>
> In a Python interactive shell? Yes.
>
> In the PDB shell? No, because some different names are defined as
> commands. Such as ‘list’.
>

Ahhh. Thanks. Time for a break.
-- 
https://mail.python.org/mailman/listinfo/python-list

Re: The next major Python version will be Python 8

[Ethan Furman]

On 03/31/2016 05:02 PM, Roel Schroeven wrote:

Victor Stinner schreef op 2016-03-31 23:40:



Python 3 becomes more and more popular and is close to a dangerous point
where it can become popular that Python 2. The PSF decided that it's
time to elaborate a new secret plan to ensure that Python users suffer
again with a new major release breaking all their legacy code.


"2016-03-31 23:40"
You're 20 minutes early :)


No, that's a naive datetime.  You need to travel to Victor's location to 
figure out what that is there.


I sure hope Python 8 doesn't have that problem!

--
~Ethan~

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

Re: Convert set to list

[Ben Finney]

Larry Martell  writes:

> I feel like I've converted sets to lists before. But maybe not. Or
> maybe I am losing it from having worked 70 hours this week.
>
> Shouldn't this work?

In a Python interactive shell? Yes.

In the PDB shell? No, because some different names are defined as
commands. Such as ‘list’.

-- 
 \  “The trouble with Communism is the Communists, just as the |
  `\   trouble with Christianity is the Christians.” —Henry L. Mencken |
_o__)  |
Ben Finney

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

[issue26681] decorators for attributes

[Ethan Furman]

Ethan Furman added the comment:

Please discuss this idea on the Python-Ideas mailing list first; if that goes 
well you can bring the idea to Python-Dev; if that also goes well feel free to 
reopen this issue.

---

In the meantime you could probably do something with a custom descriptor/class 
decorator pair; if you need help with that you could try the Python-List or 
StackOverflow.

--
nosy: +ethan.furman
resolution:  -> rejected
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

Re: The next major Python version will be Python 8

[Roel Schroeven]

Victor Stinner schreef op 2016-03-31 23:40:

Python 3 becomes more and more popular and is close to a dangerous point
where it can become popular that Python 2. The PSF decided that it's
time to elaborate a new secret plan to ensure that Python users suffer
again with a new major release breaking all their legacy code.


"2016-03-31 23:40"
You're 20 minutes early :)


--
The saddest aspect of life right now is that science gathers knowledge
faster than society gathers wisdom.
  -- Isaac Asimov

Roel Schroeven

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

Re: Convert set to list

[Chris Angelico]

On Fri, Apr 1, 2016 at 10:56 AM, Larry Martell  wrote:
> I feel like I've converted sets to lists before. But maybe not. Or
> maybe I am losing it from having worked 70 hours this week.
>
> Shouldn't this work?
>
> (Pdb) print block['relative_chart1']['vessel_names']
> set([u'Common Carotid', u'External Carotid', u'Internal Carotid'])
> (Pdb) type(block['relative_chart1']['vessel_names'])
> 
> (Pdb) list(block['relative_chart1']['vessel_names'])
> *** Error in argument: "(block['relative_chart1']['vessel_names'])"

What exactly does "Error in argument" mean? Normally I would agree,
yes, you should be able to iterate over a set exactly like that.

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

Convert set to list

[Larry Martell]

I feel like I've converted sets to lists before. But maybe not. Or
maybe I am losing it from having worked 70 hours this week.

Shouldn't this work?

(Pdb) print block['relative_chart1']['vessel_names']
set([u'Common Carotid', u'External Carotid', u'Internal Carotid'])
(Pdb) type(block['relative_chart1']['vessel_names'])

(Pdb) list(block['relative_chart1']['vessel_names'])
*** Error in argument: "(block['relative_chart1']['vessel_names'])"
-- 
https://mail.python.org/mailman/listinfo/python-list

[issue22854] Documentation/implementation out of sync for IO

[Martin Panter]

Changes by Martin Panter :


--
resolution:  -> fixed
stage: commit review -> 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

[issue26681] decorators for attributes

[Matthias welp]

New submission from Matthias welp:

This is a suggestion, and not final. 

The current ways to define the getter and setter methods for an attribute are 
these two: 

@property
def name():
""" Docstring """
pass

@name.setter
def name(value):
pass

@name.deleter
def name(value):
pass

and

name = property(getter, setter, deleter, docstring)

Of the two ways you can create a property, only the second one allows you to 
use your method definition multiple times, as seen here:

value = property(getter, setter, deleter)
value_2 = property(getter, setter, deleter)

but this has the drawback that it can only use defined method. You can go 
around by defining a wrapper method, but even then you will have to put the 
value of your attribute inside the parenthesis of your behaviour definition, 
or put another assignation statement into your file. To prevent this, I propose 
the addition of decorators to attributes, which would behave like the 
decorators on functions:

class Decorator(object):
def __init__(self, ref):
self.val = ref

def __get__(self):
return self.val

def __set__(self, val):
self.val = val

def __del__(self):
del self.val

@Decorator
val = value

@Decorator
val_2 = value_2

This should behave just like decorators on functions, but then with the 
functionality of attributes. In the proposed __init__ method ref would be the 
attribute after the evaluation of its declaration, similar to function 
decorators.

The main benefit of this would be that the definition of attributes that behave 
in a similar way (get-, set- and delete-behaviour is the same) you only have to 
define one decorator for multiple attributes and you can change the behaviour 
of your attributes in a more intuitive way. 

The current alternatives are these:

class Decorator(object):
def __init__(self, ref):
self.val = ref

def __get__(self):
return self.val

def __set__(self, val):
self.val = val

def __del__(self):
del self.val

@Decorator
def val():
pass

@Decorator
def val_2():
pass

and

def decorate(value):
_value = value
def get():
return _value
def set(value):
_value = value
def del():
del _value
return property(get, set, del)

@decorate
def val():
pass

val_2 = decorate(1)

val_3 = decorate()
val_3 = 20

I think it is weird that to create an attribute that is decorated, I need to 
create a function, or need to explicitely call the decorator. This is why the 
decorators were added for functions, I think it might as well be added for 
attributes.

--
components: Interpreter Core
messages: 262710
nosy: Matthias welp
priority: normal
severity: normal
status: open
title: decorators for attributes
type: enhancement

___
Python tracker 

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

pip.exe issue with 3.5.1

[hellofootball1 .]

So i just downloaded python 3.5.1 on my laptop and my pip.exe was not
working. It would almost immediately close on me after I clicked on it. So
i deleted the scripts folder as all of them did the same thing and then
tried the modify feature and the repair feature of your installer to try
and get pip back but it has not worked. Would you just recommend that I
install 3.4.4 and just use that instead?
-- 
https://mail.python.org/mailman/listinfo/python-list

Re: sympy

[Oscar Benjamin]

On 31 March 2016 at 22:33, Poul Riis  wrote:
> Den onsdag den 30. marts 2016 kl. 13.17.33 UTC+2 skrev Poul Riis:
>> Is it possible to transfer results from sympy to 'normal' python.
>>
>> In the case below I think my intention is clear enough but it does not work 
>> as intended. How can it be done?
>>
>> Poul Riis
>>
>> from sympy import *
>> x=Symbol('x')
>> ftext=diff(1/(x**2+1),x)
>>
>> def f(t):
>> return ftext.subs(x,'t')
>>
>> print(f(3))
>
> Well, cos(1) should have been cos(1.0) (which forces numerical evaluation, 
> try example below).
> I am just trying to implement one little thing that all CAS tools can do in a 
> few lines, namely finding the derivative of a given function followed by 
> evalution of numerical values, something like:
> define(fm(x),diff(f(x),x))
> fm(1.0)
>
> Sympy can find the derivative, and once that has been completed I would 
> expect that there is some way to find numerical values just as fast as if the 
> derivative had been given 'by hand'. But how exactly?

I assume that you're responding to me (even though your post is a
reply to yourself).

Robert Kern already answered this question earlier in the thread:

$ isympy
IPython console for SymPy 0.7.5 (Python 2.7.9-64-bit) (ground types: gmpy)

These commands were executed:
>>> from __future__ import division
>>> from sympy import *
>>> x, y, z, t = symbols('x y z t')
>>> k, m, n = symbols('k m n', integer=True)
>>> f, g, h = symbols('f g h', cls=Function)

Documentation can be found at http://www.sympy.org

In [1]: f = lambdify(x, sin(x).diff(x))

In [2]: f
Out[2]: >

In [3]: f(1)
Out[3]: 0.540302305868


We can pull apart this function f returned here:

In [4]: import dis

In [5]: dis.dis(f)
  1   0 LOAD_GLOBAL  0 (cos)
  3 LOAD_FAST0 (x)
  6 CALL_FUNCTION1
  9 RETURN_VALUE

In [6]: f.func_globals['cos']
Out[6]: 

So the function f returned by lambdify uses math.cos which is the
64-bit float function I mentioned earlier (i.e. the faster one). You
can pass an int in and it will be coerced to float. You should find
that the performance of f is as good as lambda x: math.cos(x).

So lambdify takes an expression and a sequence of symbols and
generates a function whose arguments are substituted for the sequence
of symbols. The return value of the function is the result of
substituting the arguments for the symbols in the expression. I think
this is what you asked for.

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

[issue26678] Incorrect linking to elements in datetime package

[Martin Panter]

Martin Panter added the comment:

Currently the “datetime” documentation has quick descriptions of classes marked 
up with “.. class::” in the introduction, and then dedicated sections with more 
details. Many other parts of Python’s documentation have a similar structure.

IMO it is better to include the “.. class::” markup closer to the list of 
methods, and then each method can be indented underneath it. See my changes to 
the “socketserver” documentation (Issue 15608, compare 3.4 vs 3.5) where I 
indented a whole lot of methods under class definitions. I suspect the reason 
why things are not like this is just that it is leftover from a conversion from 
an earlier markup format.

The earlier class introductions are also marked up with :noindex:, which would 
explain which become link targets.

Dunno about your intersphinx stuff though. Is that linking to the Python 
documentation from external projects?

--
nosy: +martin.panter

___
Python tracker 

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

The next major Python version will be Python 8

[Victor Stinner]

Hi,

Python 3 becomes more and more popular and is close to a dangerous point
where it can become popular that Python 2. The PSF decided that it's
time to elaborate a new secret plan to ensure that Python users suffer
again with a new major release breaking all their legacy code.

The PSF is happy to announce that the new Python release will be
Python 8!

Why the version 8? It's just to be greater than Perl 6 and PHP 7, but
it's also a mnemonic for PEP 8. By the way, each minor release will now
multiply the version by 2. With Python 8 released in 2016 and one
release every two years, we will beat Firefox 44 in 2022 (Python 64) and
Windows 2003 in 2032 (Python 2048).

A major release requires a major change to justify a version bump: the
new killer feature is that it's no longer possible to import a module
which does not respect the PEP 8. It ensures that all your code is pure.
Example:

$ python8 -c 'import keyword'
Lib/keyword.py:16:1: E122 continuation line missing indentation or outdented
Lib/keyword.py:16:1: E265 block comment should start with '# '
Lib/keyword.py:50:1: E122 continuation line missing indentation or outdented
(...)
ImportError: no pep8, no glory

Good news: since *no* module of the current standard library of Python 3
respect the PEP 8, the standard library will be simplified to one
unique module, which is new in Python 8: pep8. The standard library will
move to the Python Cheeseshop (PyPI), to reply to an old and popular
request.


DON'T PANIC! You are still able to import your legacy code into
Python 8, you just have to rename all your modules to add a "_noqa" suffix
to the filename. For example, rename utils.py to utils_noqa.py. A side
effect is that you have to update all imports. For example, replace
"import django" with "import django_noqa". After a study of the PSF,
it's a best option to split again the Python community and make sure
that all users are angry.


The plan is that in 10 years, at least 50% of the 77,000 packages on the
Python cheeseshop will be updated to get the "_noqa" tag. After 2020,
the PSF will start to sponsor trolls to harass users of the legacy
Python 3 to force them to migrate to Python 8.


Python 8 is a work-in-progress (it's still an alpha version), the
standard library was not removed yet. Hopefully, trying to import any
module of the standard library fails.

Don't hesitate to propose more ideas to make Python 8 more incompatible
with Python 3!

Note: The change is already effective in the default branch of Python:
https://hg.python.org/cpython/rev/9aedec2dbc01

Have fun,
Victor
-- 
https://mail.python.org/mailman/listinfo/python-list

Re: sympy

[Poul Riis]

Den onsdag den 30. marts 2016 kl. 13.17.33 UTC+2 skrev Poul Riis:
> Is it possible to transfer results from sympy to 'normal' python.
> 
> In the case below I think my intention is clear enough but it does not work 
> as intended. How can it be done?
> 
> Poul Riis
> 
> 
> 
> 
> from sympy import *
> x=Symbol('x')
> ftext=diff(1/(x**2+1),x)
> 
> def f(t):
> return ftext.subs(x,'t')
> 
> print(f(3))

Well, cos(1) should have been cos(1.0) (which forces numerical evaluation, try 
example below).
I am just trying to implement one little thing that all CAS tools can do in a 
few lines, namely finding the derivative of a given function followed by 
evalution of numerical values, something like:
define(fm(x),diff(f(x),x))
fm(1.0)

Sympy can find the derivative, and once that has been completed I would expect 
that there is some way to find numerical values just as fast as if the 
derivative had been given 'by hand'. But how exactly?


Poul Riis


from sympy import *
from time import *
x=Symbol('x')
ftext=diff(sin(x),x)

def fmsympy(t): 
   return ftext.evalf(subs={x:t})

def fm(t):
return cos(t)

nloop=1
tstart=time()
for i in range(0,nloop):
a=fmsympy(1)
dt1=time()-tstart
print(a)
tstart=time()
for i in range(0,nloop):
a=fm(1.0)
dt2=time()-tstart
print(a)

print(nloop,' evaluations with sympy   : dt1 =',dt1)
print(nloop,' evaluations without sympy: dt2 =',dt2)
-- 
https://mail.python.org/mailman/listinfo/python-list

ANN: python-blosc 1.3.0 released

[Francesc Alted]

=
Announcing python-blosc 1.3.0
=

What is new?


There is support for newest C-Blosc.  As such, C-Blosc 1.8.0 is being
distributed internally.  Support for the new `BITSHUFFLE` filter,
allowing for more compression ratios in many cases, at the expense of
some slowdown.  For details see:

http://python-blosc.blosc.org/tutorial.html#using-different-filters

You can also run some benchmarks including different codecs and filters:

https://github.com/Blosc/python-blosc/blob/master/bench/compress_ptr.py

For more info, you can have a look at the release notes in:

https://github.com/Blosc/python-blosc/blob/master/RELEASE_NOTES.rst

More docs and examples are available in the documentation site:

http://python-blosc.blosc.org


What is it?
===

Blosc (http://www.blosc.org) is a high performance compressor
optimized for binary data.  It has been designed to transmit data to
the processor cache faster than the traditional, non-compressed,
direct memory fetch approach via a memcpy() OS call.

Blosc is the first compressor that is meant not only to reduce the size
of large datasets on-disk or in-memory, but also to accelerate object
manipulations that are memory-bound
(http://www.blosc.org/docs/StarvingCPUs.pdf).  See
http://www.blosc.org/synthetic-benchmarks.html for some benchmarks on
how much speed it can achieve in some datasets.

Blosc works well for compressing numerical arrays that contains data
with relatively low entropy, like sparse data, time series, grids with
regular-spaced values, etc.

python-blosc (http://python-blosc.blosc.org/) is the Python wrapper for
the Blosc compression library.

There is also a handy tool built on Blosc called Bloscpack
(https://github.com/Blosc/bloscpack). It features a commmand line
interface that allows you to compress large binary datafiles on-disk.
It also comes with a Python API that has built-in support for
serializing and deserializing Numpy arrays both on-disk and in-memory at
speeds that are competitive with regular Pickle/cPickle machinery.


Installing
==

python-blosc is in PyPI repository, so installing it is easy:

$ pip install -U blosc  # yes, you must omit the 'python-' prefix


Download sources


The sources are managed through github services at:

http://github.com/Blosc/python-blosc


Documentation
=

There is Sphinx-based documentation site at:

http://python-blosc.blosc.org/


Mailing list


There is an official mailing list for Blosc at:

bl...@googlegroups.com
http://groups.google.es/group/blosc


Licenses


Both Blosc and its Python wrapper are distributed using the MIT license.
See:

https://github.com/Blosc/python-blosc/blob/master/LICENSES

for more details.



  **Enjoy data!**

-- 
Francesc Alted
-- 
https://mail.python.org/mailman/listinfo/python-announce-list

Support the Python Software Foundation:
http://www.python.org/psf/donations/

[issue22854] Documentation/implementation out of sync for IO

[Roundup Robot]

Roundup Robot added the comment:

New changeset b3c79e0ba477 by Martin Panter in branch '3.5':
Issue #22854: Fix logic for skipping test
https://hg.python.org/cpython/rev/b3c79e0ba477

New changeset de8412dc477e by Martin Panter in branch 'default':
Issue #22854: Merge test fix from 3.5
https://hg.python.org/cpython/rev/de8412dc477e

--

___
Python tracker 

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

[issue26606] logging.baseConfig is missing the encoding parameter

[Vinay Sajip]

Vinay Sajip added the comment:

> requires much more coding

Much more? How so? It just seems like one open() call and passing the result to 
basicConfig().

--

___
Python tracker 

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

[issue26488] hashlib command line interface

[Aviv Palivoda]

Changes by Aviv Palivoda :


Added file: 
http://bugs.python.org/file42337/hashlib-script-mod-md5sum-style-2.patch

___
Python tracker 

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

[issue26488] hashlib command line interface

[Aviv Palivoda]

Aviv Palivoda added the comment:

Thanks for the review SilentGhost. I am including the patch after the changes 
from your CR comments.

--

___
Python tracker 

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

Re: Pyscripter Issues

[tjohnson]

On 3/31/2016 11:29 AM, Zachary Ware wrote:

On Thursday, March 31, 2016, Simon Martin  wrote:


Hi

I have been having issues trying to run python 3.5.1 and pyscripter 2.6. Giving 
the error message that it cannot initialize python.

I have tried to re-install multiple versions of both python and pyscripter to 
no avail. Any advice?


Use PyCharm.

Less bluntly, I used to be a heavy PyScripter user, but after it took
forever for PyScripter to support Python 3.4 (I wasn't even sure if it
did yet, but it apparently does as of a year ago, added one year after
3.4 was released), I moved on.  PyScripter also has the big
disadvantage of being strictly single-platform, unlike Python itself,
so if you were to try to develop on another platform you would have to
learn a new IDE/editor anyway. I have found PyCharm to be very nice,
and very consistent cross-platform--I use it regularly on OSX and
Windows, and have also used it on Linux. I'm also becoming rather
partial to vim, which is also nicely cross-platform: if you have Git
on Windows, you have vim available already.  Vim does have a somewhat
steeper learning curve, though.
My situation is similar. I used to use PyScripter and liked it a lot, 
but when Python 3.4 support wasn't being added and I wanted a 
cross-platform IDE, I switched to PyDev.


Looking a bit deeper into what your problem might actually be,
PyScripter does not support Python 3.5.  Support for each new Python
version has to be added explicitly, and it has not been done for 3.5.]
For the record, it doesn't work with Python 2.7.11 either. PyScripter 
only supports Python <= 2.7.10 and <= 3.4.x.


But seriously, you'll be much happier with PyCharm.
Or PyDev, whichever you prefer. I think PyCharm is easier to use than 
PyDev, but it seems too resource heavy for some computers.

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

[issue26488] hashlib command line interface

[Christian Heimes]

Christian Heimes added the comment:

Threading doesn't make much sense here. The runtime of hash computation is 
usually dominated by I/O performance. On a typical consumer computer SSDs have 
a sequential read performance of 200 to 500 MiB/sec. SHA-512 performance 
between 100 to 150 Mib/sec. Threading could make parallel computation a bit 
faster, but at the cost of a much more complex implementation. Let's keep it 
simple.

Both Python's hashlib implementation and OpenSSL aren't the best foundation if 
you are aiming for maximum performance. All libraries do couple of malloc()s, 
memcpy() and have additional overheads, too.

And please don't use MD5 in your examples. Go for sha256.

--

___
Python tracker 

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

Re: Pyscripter Issues

[tjohnson]

On 3/31/2016 11:29 AM, Zachary Ware wrote:

On Thursday, March 31, 2016, Simon Martin  wrote:


Hi

I have been having issues trying to run python 3.5.1 and pyscripter 2.6. Giving 
the error message that it cannot initialize python.

I have tried to re-install multiple versions of both python and pyscripter to 
no avail. Any advice?


Use PyCharm.

Less bluntly, I used to be a heavy PyScripter user, but after it took
forever for PyScripter to support Python 3.4 (I wasn't even sure if it
did yet, but it apparently does as of a year ago, added one year after
3.4 was released), I moved on.  PyScripter also has the big
disadvantage of being strictly single-platform, unlike Python itself,
so if you were to try to develop on another platform you would have to
learn a new IDE/editor anyway. I have found PyCharm to be very nice,
and very consistent cross-platform--I use it regularly on OSX and
Windows, and have also used it on Linux. I'm also becoming rather
partial to vim, which is also nicely cross-platform: if you have Git
on Windows, you have vim available already.  Vim does have a somewhat
steeper learning curve, though.
My situation is similar. I used to use PyScripter and liked it a lot, 
but when Python 3.4 support wasn't being added and I wanted a 
cross-platform IDE, I switched to PyDev.


Looking a bit deeper into what your problem might actually be,
PyScripter does not support Python 3.5.  Support for each new Python
version has to be added explicitly, and it has not been done for 3.5.]
For the record, it doesn't work with Python 2.7.11 either. PyScripter 
only supports Python <= 2.7.10 and <= 3.4.x.


But seriously, you'll be much happier with PyCharm.
Or PyDev, whichever you prefer. I think PyCharm is easier to use than 
PyDev, but it seems too resource heavy for some computers.


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

[issue26680] Incorporating float.is_integer into the numeric tower and Decimal

[SilentGhost]

Changes by SilentGhost :


--
components: +Extension Modules
nosy: +facundobatista, mark.dickinson, rhettinger, skrah
stage:  -> patch review
versions: +Python 3.6

___
Python tracker 

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

[issue26680] Incorporating float.is_integer into the numeric tower and Decimal

[Robert Smallshire]

Robert Smallshire added the comment:

Adding the second patch file.

--
Added file: http://bugs.python.org/file42336/is_integer_decimal.patch

___
Python tracker 

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

[issue26488] hashlib command line interface

[SilentGhost]

SilentGhost added the comment:

The mailing system is acting up, so just for the record, I've left comments on 
rietveld regarding md5sum-style patch.

--

___
Python tracker 

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

[issue26680] Incorporating float.is_integer into the numeric tower and Decimal

[Robert Smallshire]

New submission from Robert Smallshire:

When the useful float.is_integer method was added the opportunity was missed to 
incorporate this method into the numeric tower defined in numbers.py. This 
increased the API distance between different number types, making them less 
substitutable than previously, leading to what might be considered to be absurd 
behaviour:

  >>> a = 5.0
  >>> b = 5
  >>> a.is_integer()
  True
  >>> b.is_integer()
  Traceback (most recent call last):
File "", line 1, in 
  AttributeError: 'int' object has no attribute 'is_integer'

The first attached patch modifies Python to:

 1) Implement int.is_integer() to always return True
 2) Add Real.is_integer() as an abstract method in numbers.py
 3) Provide a default implementation in Rational.is_integer() in numbers.py
 4) Adds tests for is_integer() for int and Fraction.
 5) Documentation changes commensurate with above.

Although the Decimal type deliberately lies outside the numeric tower for 
reasons not relevant here, the principle of least surprise suggests that it too 
should support is_integer().  In fact, the implementation already contains just 
such a function, although it is not exposed to Python.  The second patch 
implements is_integer() for both the pure Python and C implementations of 
Decimal, again with commensurate tests and documentation changes.

I hope these changes can be implemented to reduce the degree of surprise 
encountered when working with different number types in Python.

--
components: Library (Lib)
files: is_integer_numeric_tower.patch
keywords: patch
messages: 262702
nosy: Robert Smallshire2
priority: normal
severity: normal
status: open
title: Incorporating float.is_integer into the numeric tower and Decimal
type: enhancement
Added file: http://bugs.python.org/file42335/is_integer_numeric_tower.patch

___
Python tracker 

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

[issue26679] curses: Descripton of KEY_NPAGE and KEY_PPAGE inverted

[Robert Bachmann]

New submission from Robert Bachmann:

The table on 
lists:
__
Page Up KEY_NPAGE
Page Down   KEY_PPAGE
__

it should be vice versa.

--
assignee: docs@python
components: Documentation
files: curses.patch
keywords: patch
messages: 262701
nosy: Robert Bachmann, docs@python
priority: normal
severity: normal
status: open
title: curses: Descripton of KEY_NPAGE and KEY_PPAGE inverted
type: enhancement
versions: Python 2.7, Python 3.5, Python 3.6
Added file: http://bugs.python.org/file42334/curses.patch

___
Python tracker 

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

Re: Slice equivalent to dict.get

[Zachary Ware]

On Thu, Mar 31, 2016 at 12:51 PM, Terry Reedy  wrote:
> On 3/31/2016 11:24 AM, Peter Otten wrote:
>> try...except to the rescue:
>>
> def get(seq, index, default=None):
>>
>> ... try: return seq[index]
>> ... except IndexError: return default
>
>
> Replace IndexError with (IndexError, KeyError) and the functions works with
> any subscriptable that raises either exception.

Or use the superclass of both of those, LookupError, and also catch
anything that uses that more generic name as well.

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

Re: sympy

[Oscar Benjamin]

On 31 March 2016 at 11:57, Poul Riis  wrote:
>
> ... However, the sympy way seems to be about 70 times slower than using the 
> derivative calculated 'by hand' (try the example below).
> Can it be done in a more efficient way?
>
> Poul Riis
>
>
>
> from sympy import *
> from time import *
> x=Symbol('x')
> ftext=diff(sin(x),x)
>
> def fmsympy(t):
>return ftext.evalf(subs={x:t})
>
> def fm(t):
> return cos(t)

I think you have misunderstood what is going on here. Let's actually
try those two methods out:

$ isympy
IPython console for SymPy 0.7.5 (Python 2.7.9-64-bit) (ground types: gmpy)

These commands were executed:
>>> from __future__ import division
>>> from sympy import *
>>> x, y, z, t = symbols('x y z t')
>>> k, m, n = symbols('k m n', integer=True)
>>> f, g, h = symbols('f g h', cls=Function)

Documentation can be found at http://www.sympy.org

In [1]: ftext = diff(sin(x), x)

In [2]: ftext
Out[2]: cos(x)

In [3]: ftext.evalf(subs={x:1})
Out[3]: 0.540302305868140

In [4]: cos(1)
Out[4]: cos(1)

So the first version (your fmsympy) takes the symbolic expression
cos(x) represented as a sympy expression tree and substitutes 1 for x
(which requires walking the tree to look fo all occurrences of x).
Then it evaluates the result to 15 decimal digits of precision using
the pure Python mpmath multiprecision math library. To prove that it's
not really a float calculation let's increase the precision:

In [5]: ftext.evalf(subs={x:1}, n=100)
Out[5]: 
0.540302305868139717400936607442976603732310420617976700972553811003947744717645179518560871830893

Your second version (fm) makes a sympy expression using the cos
function from sympy and the argument 1. This creates a symbolic sympy
expression cos(1) and returns that. It doesn't do any evaluation of
the expression to get the digits of the actual numeric answer.

So I'm not surprised that the two operations take different amounts of
time. One doesn't evaluate the expression and the other does using a
slow multiprecision library. Also note though that sympy uses a cache
to accelerate repeated calculations so if you time it doing the exact
same thing repeatedly in a loop then you may just be measuring
cache-hit performance for two different inputs rather than actual
evaluation time.

If you want to see one that's a lot faster use the cos function from
the math module:

In [9]: from math import cos

In [10]: cos(1)
Out[10]: 0.540302305868

This calculates cos(1) using IEEE 64-bit binary floating point
(Python's float type) with hardware acceleration from your processor's
FPU instructions. This should be a lot faster then either substituting
into symbolic expressions in sympy or evaluating trignometric
functions with mpmath.

Generally I would use sympy in order to derive the mathematical
expressions that I want to compute. However if I then want to evaluate
the expressions many times in a loop with different input numbers for
example then I would rewrite the expression without using sympy. Sympy
has code generation capabilities to automate this but you seemed to be
confused about basic sympy usage right now so I wouldn't recommend
them without knowing more about what you're trying to do.

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

[issue26606] logging.baseConfig is missing the encoding parameter

[Jānis Šlapiņš]

Jānis Šlapiņš added the comment:

Using the stream or other options requires much more coding (for example, an 
additional redirection of sys.stdout to a file) instead of just one line with 
the basicConfig.

In the meanwhile, I tried to use logging.FileHandler instead where I could 
specify the encoding in parameters and it works as I wanted when used the 
basicConfig method.

Anyway, it would be nice to have the encoding parameter among the basicConfig 
parameters when logging to files.

--

___
Python tracker 

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

[issue26488] hashlib command line interface

[Aviv Palivoda]

Aviv Palivoda added the comment:

I am adding a new patch with a API compatible to GNU md5sum:

$ python -m hashlib md5 /bin/sh
$ d985d0ea551c1253c2305140c583d11f /bin/sh

I will soon add the feature's requested by Victor:
  1) The check option.
  2) Running the hash calculation for different files in different threads.

If anyone would like any other feature he thinks will be helpful please post it.

If we choose to use this API we should remove the dependency on issue 14156.

--
Added file: 
http://bugs.python.org/file42333/hashlib-script-mod-md5sum-style.patch

___
Python tracker 

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

Re: sympy

[Peter Otten]

Chris Angelico wrote:

> On Fri, Apr 1, 2016 at 1:55 AM, Peter Otten <__pete...@web.de> wrote:
>> Hm, the two functions fmsympy() and fm() do not return the same value:
>>
>> $ python -i sympy_diff.py
>> 1  evaluations with sympy   : dt1 = 0.7178411483764648
>> 1  evaluations without sympy: dt2 = 0.10177111625671387
> fm(42)
>> cos(42)
> fmsympy(42)
>> -0.399985314988351
>>
> 
> Maybe not, but that's simply because one of them is completely
> evaluated. The cosine of 42 radians is indeed -0.4ish.
> 
 math.cos(42)
> -0.39998531498835127

My guess was that the OP fell into the trap that he himself carefully set up 
with the star import, and accidentally used sympy.cos() where he wanted to 
invoke math.cos().

The fix would actually increase the speed difference -- but first make it 
right, then, maybe, fast.

Adding another storey to the tower of guesses, Robert Kern has probably 
already provided the answer ;)

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

Re: Slice equivalent to dict.get

[Terry Reedy]

On 3/31/2016 11:24 AM, Peter Otten wrote:

Steven D'Aprano wrote:


Sometimes people look for a method which is equivalent to dict.get, where
they can set a default value for when the key isn't found:


py> d = {1: 'a', 2: 'b'}
py> d.get(999, '?')
'?'


The equivalent for sequences such as lists and tuples is a slice. If the
slice is out of range, Python returns a empty sequence:

py> L = [2, 4, 8, 16]
py> L[5]  # out of range, raises IndexError
Traceback (most recent call last):
   File "", line 1, in 
IndexError: list index out of range
py> L[5:6]  # out of range slice return empty list
[]

To get a default:

py> L[5:6] or -1
-1


This is short and simple enough to use in place, but we can also wrap this
into a convenient helper function:

def get(seq, index, default=None):
 return (seq[index:index+1] or [default])[0]



py> get(L, 2, -1)
8
py> get(L, 200, -1)
-1


But note:


def get(seq, index, default=None):

... return (seq[index:index+1] or [default])[0]
...

get("abc", -1, "default")

'default'

God old try...except to the rescue:


def get(seq, index, default=None):

... try: return seq[index]
... except IndexError: return default


Replace IndexError with (IndexError, KeyError) and the functions works 
with any subscriptable that raises either exception.



...

get("abc", -1, "default")

'c'





--
Terry Jan Reedy

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

Re: Suggestion: make sequence and map interfaces more similar

[Terry Reedy]

On 3/31/2016 10:13 AM, Marko Rauhamaa wrote:


One could compose a table of correspondences:


with some corrections


   ---
   list (L)dict (D)
   ---
   L[key] = value  D[key] = value
   del L[key] (*)  del L[key]
   (*) reassigns all keys
   key >= 0 and key < len(L)   key in D


'-len(L) <= key < len(L)' or 'key in range(-len(L), len(L)'
Lists, tuples, and ranges have 2 keys for each value,
though that is not guaranteed for sequences in general.

key in D == key in D.keys()


   range(len(L))   iter(D)


 iter(range(Len(L))  == iter(D.keys())


   L.clear D.clear
   L.copy  D.copy
   lambda key: L[key]  D.get


The purpose of D.get() is to supply a default instead of raising 
KeyError when key not in D. The lambda function above does not do that. 
 Turning subscripting into a function is a side-effect of D.get.  A 
generic get function:


def get(subscriptable, key, default=None):
try:
return subscriptable[key]
except (IndexError, KeyError):
return default


   lambda: enumerate(L)D.items


As I pointed out a couple days ago, an enumerate iterator is quite 
different from a set-like dynamic view.  An actual correspondence:


 enumerate(L)   iter(D.items())

Writing a set-like dynamic view of lists corresponding to D.values() or 
D.items() would be an interesting project.



   lambda: range(len(L))   D.keys


 iter(range(len(L))  iter(D.keys())
Already given above.  Iterating indexes is now much rarer than iterating 
dict keys.


--
Terry Jan Reedy

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

[issue26678] Incorrect linking to elements in datetime package

[Andy Maier]

New submission from Andy Maier:

Hi, I did search for these in the open bugs, but did not find any matching bug.

I have a project that revealed that some of its InterSphinx links to existing 
classes/types or methods to not resolve their targets, or to resolve to a 
target that is not the right one (IMO).

This issue here describes everything I found in the datetime package.

Line numbers in this issue apply to the datetime.rst file as of commit 
96a98bcaac70 
(https://hg.python.org/cpython/file/96a98bcaac70/Doc/library/datetime.rst).

* class datetime.tzinfo:

  An intersphinx link to it gets resolved but targets the short description of 
the class in the intro (line 106 of datetime.rst), and I did not find a way to 
target the full description (line 1552), which is really what this should be 
resolved to (IMO).

  I suspect that this has to do with the fact that this class has only one 
anchor on its short description on line 106, while companion classes such as 
datetime.datetime have two anchors (lines 91 and 681) where the last one wins 
(and happens to be the long description). However, see the next item.

* class datetime.timezone:

  Same issue as for class datetime.tzinfo; links get resolved but land on the 
short intro. However, this time there are two anchors (lines 113 and 1795). So 
maybe my suspicion above is rather speculation...

* method datetime.tzinfo.utcoffset:

  An intersphinx link to it does not get resolved. On line 1579 in 
datetime.rst, there is a `.. method:: tzinfo.utcoffset(dt)` but at least these 
intersphinx links did not get resolved:

  :func:`py:tzinfo.utcoffset`
  :func:`py:datetime.tzinfo.utcoffset`

  Do method anchors need the anchor for their defining class close by to work? 
Which because if the first issue above, would be the short version of it, way 
above. (Again speculation)

* Same for method datetime.tzinfo.dst

--
assignee: docs@python
components: Documentation
messages: 262698
nosy: andymaier, docs@python
priority: normal
severity: normal
status: open
title: Incorrect linking to elements in datetime package
type: enhancement
versions: Python 3.6

___
Python tracker 

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

[issue26632] __all__ decorator

[Barry A. Warsaw]

Barry A. Warsaw added the comment:

On Mar 25, 2016, at 02:12 AM, Eryk Sun wrote:

>I added a prototype to Python/bltinmodule.c that gets or creates the __all__
>list from the current globals (i.e. PyEval_GetGlobals).

Hi Eryk.  Can you post your diff to bltinmodule.c?  I'd like to see your code.

>It accepts at most one positional argument and any number of keyword
>arguments. It adds the positional argument's __name__ to __all__, sets it in
>globals, and returns a reference for use as a decorator. The keyword argument
>dict is used to update globals and extend __all__.

I like this.  The dual functionality of `public` looks like it will handle
almost all use cases.  I think we're in widespread agreement about the
decorator, and the keyword arguments are a nice approach to public constants.

I guess I'm a little less sure about the positional argument API.  In adding
@public to Mailman, I noticed there are a few public names which are
instances.  These could be "publicized" with the keyword argument approach,
but I don't think they can work as positional arguments, because the instances
themselves don't have __name__s.  For example, currently:

factory = DateFactory()
factory.reset()
today = factory.today
now = factory.now
layers.MockAndMonkeyLayer.register_reset(factory.reset)

__all__.extend([
'factory',
'now',
'today',
])

With only keyword arguments, which isn't bad:

public(factory=DateFactory())
factory.reset()
public(today=factory.today, now=factor.now)

What's the use case for positionals?

>The positional argument must have a __name__ that's a string:

Right.  But what class of objects does that cover that isn't already covered
(or that explicitly appending to __all__ is good enough)?

--

___
Python tracker 

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

Re: sympy

[Chris Angelico]

On Fri, Apr 1, 2016 at 1:55 AM, Peter Otten <__pete...@web.de> wrote:
> Hm, the two functions fmsympy() and fm() do not return the same value:
>
> $ python -i sympy_diff.py
> 1  evaluations with sympy   : dt1 = 0.7178411483764648
> 1  evaluations without sympy: dt2 = 0.10177111625671387
 fm(42)
> cos(42)
 fmsympy(42)
> -0.399985314988351
>

Maybe not, but that's simply because one of them is completely
evaluated. The cosine of 42 radians is indeed -0.4ish.

>>> math.cos(42)
-0.39998531498835127

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

Re: Learning Python (or Haskell) makes you a worse programmer

[Sven R. Kunze]

On 31.03.2016 18:30, Travis Griggs wrote:



British:  http://www.oxforddictionaries.com/definition/english/python
American: http://www.dictionary.com/browse/python?s=t

That does it. If I ever make some sort of open source module for pythun/pythawn 
I’ll be sure to call it either tuhmayto/tomawto. Or maybe I’ll call it 
puhtayto/potawto.


Isn't it more like "Pythn"?
--
https://mail.python.org/mailman/listinfo/python-list

Re: Learning Python (or Haskell) makes you a worse programmer

[Ian Kelly]

On Thu, Mar 31, 2016 at 10:30 AM, Travis Griggs  wrote:
>
>> On Mar 30, 2016, at 2:36 PM, Gregory Ewing  
>> wrote:
>>
>> Tim Golden wrote:
>>
>>> (I don't know how other English-speaking groups say the word, but in
>>> England the first syllable is stressed and the second is the
>>> conventional short "uh" sound).
>>
>> I can attest that New Zealand follows the UK on this. I was
>> surprised when I first heard an American pronounce it too.
>>
>> The curious can hear the difference on these pages:
>>
>> British:  http://www.oxforddictionaries.com/definition/english/python
>> American: http://www.dictionary.com/browse/python?s=t
>
> That does it. If I ever make some sort of open source module for 
> pythun/pythawn I’ll be sure to call it either tuhmayto/tomawto. Or maybe I’ll 
> call it puhtayto/potawto.

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

Re: Learning Python (or Haskell) makes you a worse programmer

[Travis Griggs]

> On Mar 30, 2016, at 2:36 PM, Gregory Ewing  
> wrote:
> 
> Tim Golden wrote:
> 
>> (I don't know how other English-speaking groups say the word, but in
>> England the first syllable is stressed and the second is the
>> conventional short "uh" sound).
> 
> I can attest that New Zealand follows the UK on this. I was
> surprised when I first heard an American pronounce it too.
> 
> The curious can hear the difference on these pages:
> 
> British:  http://www.oxforddictionaries.com/definition/english/python
> American: http://www.dictionary.com/browse/python?s=t

That does it. If I ever make some sort of open source module for pythun/pythawn 
I’ll be sure to call it either tuhmayto/tomawto. Or maybe I’ll call it 
puhtayto/potawto.

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

[issue26677] pyvenv: activate.fish breaks $PATH for bash scripts

[SilentGhost]

Changes by SilentGhost :


--
nosy: +vinay.sajip
type:  -> behavior

___
Python tracker 

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

Re: Slice equivalent to dict.get

[Sven R. Kunze]

On 31.03.2016 17:07, Steven D'Aprano wrote:

Sometimes people look for a method which is equivalent to dict.get, where
they can set a default value for when the key isn't found:


py> d = {1: 'a', 2: 'b'}
py> d.get(999, '?')
'?'


The equivalent for sequences such as lists and tuples is a slice. If the
slice is out of range, Python returns a empty sequence:


I see what you are trying to achieve here. What do you think about this?

[1, 2, 3].get(999, '?')


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

[issue26677] pyvenv: activate.fish breaks $PATH for bash scripts

[Florian Dold]

New submission from Florian Dold:

When sourcing the activate script from bash, $PATH is restored from 
$_OLD_VIRTUAL_PATH.  If bash was invoked from fish (e.g. when running a shell 
script), and a virtualenv was activated from fish via activate.fish, the 
$_OLD_VIRTUAL_PATH will contain path separated by the ascii record separator 
char (chr(30)), since this is how the fish shell stores arrays.

But the activate script for bash will then set $PATH to $_OLD_VIRTUAL_PATH, 
which breaks most bash scripts.

Instead the activate scripts should differentiate between

$_OLD_BASH_VIRTUAL_PATH
and
$_OLD_FISH_VIRTUAL_PATH

or the activate.fish should take care to replace chr(30) with colons before it 
sets $_OLD_VIRTUAL_PATH.


bash$ pyvenv my-venv
bash$ fish
fish$ . my-venv/bin/activate.fish
fish$ bash
bash$ . my-venv/bin/activate
# $PATH is now broken, since it contains record separators instead of colons to 
separate paths

--
components: Library (Lib)
messages: 262696
nosy: Florian.Dold
priority: normal
severity: normal
status: open
title: pyvenv: activate.fish breaks $PATH for bash scripts
versions: Python 3.5

___
Python tracker 

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

Re: Slice equivalent to dict.get

[Ian Kelly]

On Thu, Mar 31, 2016 at 9:24 AM, Peter Otten <__pete...@web.de> wrote:
> But note:
>
 def get(seq, index, default=None):
> ... return (seq[index:index+1] or [default])[0]
> ...
 get("abc", -1, "default")
> 'default'

The discontinuity between -1 and 0 in indexing is a pain in the rear.
Negative indexes are one of those things that may seem like a good
idea at first, but I think in the end it causes more trouble than it's
worth. There's nothing you can do with L[-x] that you can't do more
explicitly with L[len(L) - x].
-- 
https://mail.python.org/mailman/listinfo/python-list

Re: Pyscripter Issues

[John Gordon]

In  Simon Martin 
 writes:

> I have been having issues trying to run python 3.5.1 and pyscripter 2.6.
> Giving the error message that it cannot initialize python.

Which version of Python did you get: 32-bit or 64-bit?  I vaguely recall
that PyScripter won't work with the 64-bit version.

-- 
John Gordon   A is for Amy, who fell down the stairs
gor...@panix.com  B is for Basil, assaulted by bears
-- Edward Gorey, "The Gashlycrumb Tinies"

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

Re: Pyscripter Issues

[Zachary Ware]

On Thursday, March 31, 2016, Simon Martin  wrote:
>
> Hi
>
> I have been having issues trying to run python 3.5.1 and pyscripter 2.6. 
> Giving the error message that it cannot initialize python.
>
> I have tried to re-install multiple versions of both python and pyscripter to 
> no avail. Any advice?

Use PyCharm.

Less bluntly, I used to be a heavy PyScripter user, but after it took
forever for PyScripter to support Python 3.4 (I wasn't even sure if it
did yet, but it apparently does as of a year ago, added one year after
3.4 was released), I moved on.  PyScripter also has the big
disadvantage of being strictly single-platform, unlike Python itself,
so if you were to try to develop on another platform you would have to
learn a new IDE/editor anyway. I have found PyCharm to be very nice,
and very consistent cross-platform--I use it regularly on OSX and
Windows, and have also used it on Linux. I'm also becoming rather
partial to vim, which is also nicely cross-platform: if you have Git
on Windows, you have vim available already.  Vim does have a somewhat
steeper learning curve, though.

Looking a bit deeper into what your problem might actually be,
PyScripter does not support Python 3.5.  Support for each new Python
version has to be added explicitly, and it has not been done for 3.5.
If you still want to use PyScripter, you should use the latest release
of Python 3.4.  Keep in mind that you must match use 32-bit Python
with 32-bit PyScripter, and 64-bit Python with 64-bit PyScripter, you
cannot mix and match.

But seriously, you'll be much happier with PyCharm.

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

Re: Slice equivalent to dict.get

[Peter Otten]

Steven D'Aprano wrote:

> Sometimes people look for a method which is equivalent to dict.get, where
> they can set a default value for when the key isn't found:
> 
> 
> py> d = {1: 'a', 2: 'b'}
> py> d.get(999, '?')
> '?'
> 
> 
> The equivalent for sequences such as lists and tuples is a slice. If the
> slice is out of range, Python returns a empty sequence:
> 
> py> L = [2, 4, 8, 16]
> py> L[5]  # out of range, raises IndexError
> Traceback (most recent call last):
>   File "", line 1, in 
> IndexError: list index out of range
> py> L[5:6]  # out of range slice return empty list
> []
> 
> To get a default:
> 
> py> L[5:6] or -1
> -1
> 
> 
> This is short and simple enough to use in place, but we can also wrap this
> into a convenient helper function:
> 
> def get(seq, index, default=None):
> return (seq[index:index+1] or [default])[0]
> 
> 
> 
> py> get(L, 2, -1)
> 8
> py> get(L, 200, -1)
> -1

But note:

>>> def get(seq, index, default=None):
... return (seq[index:index+1] or [default])[0]
... 
>>> get("abc", -1, "default")
'default'

God old try...except to the rescue:

>>> def get(seq, index, default=None):
... try: return seq[index]
... except IndexError: return default
... 
>>> get("abc", -1, "default")
'c'


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

Slice equivalent to dict.get

[Steven D'Aprano]

Sometimes people look for a method which is equivalent to dict.get, where
they can set a default value for when the key isn't found:


py> d = {1: 'a', 2: 'b'}
py> d.get(999, '?')
'?'


The equivalent for sequences such as lists and tuples is a slice. If the
slice is out of range, Python returns a empty sequence:

py> L = [2, 4, 8, 16]
py> L[5]  # out of range, raises IndexError
Traceback (most recent call last):
  File "", line 1, in 
IndexError: list index out of range
py> L[5:6]  # out of range slice return empty list
[]

To get a default:

py> L[5:6] or -1
-1


This is short and simple enough to use in place, but we can also wrap this
into a convenient helper function:

def get(seq, index, default=None):
return (seq[index:index+1] or [default])[0]



py> get(L, 2, -1)
8
py> get(L, 200, -1)
-1



-- 
Steven

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

[issue26671] Clean up path_converter in posixmodule.c

[Larry Hastings]

Larry Hastings added the comment:

I approve in principle, but this patch isn't ready.

If we compile on Win32, and allow_fd is on, and they pass in an invalid fd, 
your patched code will reach line 914 "length = PyBytes_GET_SIZE(bytes);" but 
bytes will be uninitialized.

--

___
Python tracker 

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

Re: Pyscripter Issues

[Steven D'Aprano]

On Fri, 1 Apr 2016 12:45 am, Simon Martin wrote:

> Hi
> 
> I have been having issues trying to run python 3.5.1 and pyscripter 2.6.
> Giving the error message that it cannot initialize python.
> 
> I have tried to re-install multiple versions of both python and pyscripter
> to no avail. Any advice?

Yes: start by copying and pasting the full error message here, so we can
read it, rather than summarising it.

Generally speaking, re-installing Python should be your last resort. At the
very least, there's no point in re-installing until you can be sure that
Python itself is broken.

What happens if you run "python3" from the command prompt? I've barely
touched Windows for probably eight years, and I have no idea how to get a
command prompt in Windows 10, but if you can get command.com or cmd.exe
(whichever it is) and try running Python from that, you'll soon find out
whether Python itself is working.



-- 
Steven

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

Re: sympy

[Peter Otten]

Poul Riis wrote:

> Den onsdag den 30. marts 2016 kl. 17.59.49 UTC+2 skrev Steven D'Aprano:
>> On Thu, 31 Mar 2016 02:23 am, Poul Riis wrote:
>> 
>> > What I intend to do is to let sympy find the derivative of some
>> > welldefined function and next define the foundation derivative as a
>> > normal function so that I can calculate numerical values or even make a
>> > graph.
>> 
>> 
>> I'm glad you explained what you *actually* wanted, because I was going to
>> guess that you wanted to evaluate the derivative at x = 3:
>> 
>> 
>> py> ftext.evalf(subs={x:3})
>> -0.0600
>> 
>> 
>> 
>> --
>> Steven
> 
> ... However, the sympy way seems to be about 70 times slower than using
> the derivative calculated 'by hand' (try the example below). Can it be
> done in a more efficient way?

Hm, the two functions fmsympy() and fm() do not return the same value:

$ python -i sympy_diff.py 
1  evaluations with sympy   : dt1 = 0.7178411483764648
1  evaluations without sympy: dt2 = 0.10177111625671387
>>> fm(42)
cos(42)
>>> fmsympy(42)
-0.399985314988351

What's the point of that benchmark?

> Poul Riis
> 
> 
> 
> from sympy import *
> from time import *
> x=Symbol('x')
> ftext=diff(sin(x),x)
> 
> def fmsympy(t):
>return ftext.evalf(subs={x:t})
> 
> def fm(t):
> return cos(t)
> 
> nloop=1
> tstart=time()
> # nloop evaluations with sympy
> for i in range(0,nloop):
> a=fmsympy(1)
> dt1=time()-tstart
> 
> # nloop evaluations without sympy
> tstart=time()
> for i in range(0,nloop):
> a=fm(1)
> dt2=time()-tstart
> 
> print(nloop,' evaluations with sympy   : dt1 =',dt1)
> print(nloop,' evaluations without sympy: dt2 =',dt2)


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

Re: Suggestion: make sequence and map interfaces more similar

[Marko Rauhamaa]

Jussi Piitulainen :

> operator.itemgetter(*selector)(fields) # ==> ('y', 'y', 'x')
>
> [...]
>
> operator.itemgetter(*selector)(field_dict) # ==> ('y', 'y', 'x')
>
> It's not quite the same but it's close and it works the same for
> strings, lists, dicts, ...

Not quite the same, but nicely found anyway.


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

Re: Suggestion: make sequence and map interfaces more similar

[Marko Rauhamaa]

Random832 :

> So can we discuss how a unified method to get a set of all valid
> subscripts (and/or subscript-value pairs) on an object would be a
> useful thing to have without getting bogged down in theoretical
> claptrap about the meaning of the mapping contract?

One could compose a table of correspondences:

  ---
  list (L)dict (D)   
  ---
  L[key] = value  D[key] = value
  del L[key] (*)  del L[key] 
  key >= 0 and key < len(L)   key in D
  range(len(L))   iter(D)
  L.clear D.clear
  L.copy  D.copy
  lambda key: L[key]  D.get
  lambda: enumerate(L)D.items
  lambda: range(len(L))   D.keys
 ......
  ---
  (*) reassigns all keys


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

Re: Suggestion: make sequence and map interfaces more similar

[Mark Lawrence via Python-list]

On 31/03/2016 14:27, Random832 wrote:

On Thu, Mar 31, 2016, at 09:17, Mark Lawrence via Python-list wrote:

On 31/03/2016 14:08, Antoon Pardon wrote:

Op 31-03-16 om 13:57 schreef Chris Angelico:

Okay. I'll put a slightly different position: Prove that your proposal
is worth discussing by actually giving us an example that we can
discuss. So far, this thread has had nothing but toy examples (and
bogoexamples that prove nothing beyond that the author knows how to
mess with Python - fun, but not a strong argument on either side).
Give us some real meat to work with, instead of these drips of
tantalizing blood.


What a strange request. Whether or not something is worth discussing
is a personal judgement. So there can be no proof of such a thing.
I would say: judge for yourself and act accordingly.


Drivel.  This is comp.lang.python, where "Practicality beats purity"
every time, not comp.theoretical.claptrap.


So can we discuss how a unified method to get a set of all valid
subscripts (and/or subscript-value pairs) on an object would be a useful
thing to have without getting bogged down in theoretical claptrap about
the meaning of the mapping contract?



We can discuss anything here until the cows come home, but it's a 
complete waste of time if the powers that be over on python-ideas and/or 
python-dev don't agree.  This was suggested a day or two back but seems 
to have gone completely over people's heads.


--
My fellow Pythonistas, ask not what our language can do for you, ask
what you can do for our language.

Mark Lawrence

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

Re: Suggestion: make sequence and map interfaces more similar

[Marko Rauhamaa]

Chris Angelico :

> Or, even more likely and even more Pythonic:
>
 [fields[i] for i in selector]
> ['y', 'y', 'x']
>
> As soon as you get past the easy and obvious case of an existing
> function, filter and map quickly fall behind comprehensions in utility
> and readability.

The general need is contexts where you need fields[?] act as a function.
Of course,

   lambda i: fields[i]

does it. However, weirdly, dicts have get but lists don't.

Ok, dict.get() provides for a default value, but couldn't that come in
handy for lists as well?

Again, lambda would do it for both dicts and lists:

   lambda i: fields[i] if i >= 0 and i < len(fields) else default

   lambda key: fields[key] if key in fields else default


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

Pyscripter Issues

[Simon Martin]

Hi

I have been having issues trying to run python 3.5.1 and pyscripter 2.6. Giving 
the error message that it cannot initialize python.

I have tried to re-install multiple versions of both python and pyscripter to 
no avail. Any advice?

Thanks

Simon

Sent from Mail for Windows 10

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

Re: Suggestion: make sequence and map interfaces more similar

[Rustom Mody]

On Thursday, March 31, 2016 at 6:38:56 PM UTC+5:30, Antoon Pardon wrote:
> Op 31-03-16 om 13:57 schreef Chris Angelico:
> > Okay. I'll put a slightly different position: Prove that your proposal
> > is worth discussing by actually giving us an example that we can
> > discuss. So far, this thread has had nothing but toy examples (and
> > bogoexamples that prove nothing beyond that the author knows how to
> > mess with Python - fun, but not a strong argument on either side).
> > Give us some real meat to work with, instead of these drips of
> > tantalizing blood.
> 
> What a strange request. Whether or not something is worth discussing
> is a personal judgement. So there can be no proof of such a thing.
> I would say: judge for yourself and act accordingly.

Not been following this thread much
And not much interest in the suggestion/request
Just thought I'd give a take on what may be the motivation for this

There is the allure of One-Fundamental-Data-structure
Lisp calls that 'list'
[40 years after with more fanfare and less clarity replicated as XML]

Math calls that 'function'
Even more fundamental in CS than in math
That maps are same as functions is standard math.
In python one interconverts data→code by going from dict d to d.get
code→data by memoization/caching
How about a Grand Unified Theory?

[Just to be clear -- not my interest or wish]
-- 
https://mail.python.org/mailman/listinfo/python-list

Re: Suggestion: make sequence and map interfaces more similar

[Random832]

On Thu, Mar 31, 2016, at 09:17, Mark Lawrence via Python-list wrote:
> On 31/03/2016 14:08, Antoon Pardon wrote:
> > Op 31-03-16 om 13:57 schreef Chris Angelico:
> >> Okay. I'll put a slightly different position: Prove that your proposal
> >> is worth discussing by actually giving us an example that we can
> >> discuss. So far, this thread has had nothing but toy examples (and
> >> bogoexamples that prove nothing beyond that the author knows how to
> >> mess with Python - fun, but not a strong argument on either side).
> >> Give us some real meat to work with, instead of these drips of
> >> tantalizing blood.
> >
> > What a strange request. Whether or not something is worth discussing
> > is a personal judgement. So there can be no proof of such a thing.
> > I would say: judge for yourself and act accordingly.
> 
> Drivel.  This is comp.lang.python, where "Practicality beats purity" 
> every time, not comp.theoretical.claptrap.

So can we discuss how a unified method to get a set of all valid
subscripts (and/or subscript-value pairs) on an object would be a useful
thing to have without getting bogged down in theoretical claptrap about
the meaning of the mapping contract?
-- 
https://mail.python.org/mailman/listinfo/python-list

Re: Suggestion: make sequence and map interfaces more similar

[Mark Lawrence via Python-list]

On 31/03/2016 14:08, Antoon Pardon wrote:

Op 31-03-16 om 13:57 schreef Chris Angelico:

Okay. I'll put a slightly different position: Prove that your proposal
is worth discussing by actually giving us an example that we can
discuss. So far, this thread has had nothing but toy examples (and
bogoexamples that prove nothing beyond that the author knows how to
mess with Python - fun, but not a strong argument on either side).
Give us some real meat to work with, instead of these drips of
tantalizing blood.


What a strange request. Whether or not something is worth discussing
is a personal judgement. So there can be no proof of such a thing.
I would say: judge for yourself and act accordingly.



Drivel.  This is comp.lang.python, where "Practicality beats purity" 
every time, not comp.theoretical.claptrap.


--
My fellow Pythonistas, ask not what our language can do for you, ask
what you can do for our language.

Mark Lawrence

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

Re: Suggestion: make sequence and map interfaces more similar

[Mark Lawrence via Python-list]

On 31/03/2016 13:49, Marco Sulla via Python-list wrote:


On 31 March 2016 at 14:30, Mark Lawrence via Python-list
 wrote:

Note that dict also supports
__getitem__() and __len__(), but is considered a mapping rather than a
sequence because the lookups use arbitrary immutable keys rather than
integers.


Thank you for confirming for what I already wrote and quoted, but I suppose you
missed some of my previous messages, my dear friend.



Thanks for misquoting me by deliberately snipping the bit about taking 
this completely useless discussion offline.  Please do not "dear friend" 
me as I don't take kindly to people who go out of their way to waste 
time and effort on this list.  This just isn't going to happen, so 
please drop it, or do you not realise when you're fighting a losing 
battle, and it's time to retreat?


There are of course other options, you could join in the effort to 
produce Python 2.8 or RickedPython.  I'm sure that they'd welcome some 
additional help and your patch for your absolutely awesome suggestion.


--
My fellow Pythonistas, ask not what our language can do for you, ask
what you can do for our language.

Mark Lawrence

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

Re: Suggestion: make sequence and map interfaces more similar

[Chris Angelico]

On Fri, Apr 1, 2016 at 12:08 AM, Antoon Pardon
 wrote:
> Op 31-03-16 om 13:57 schreef Chris Angelico:
>> Okay. I'll put a slightly different position: Prove that your proposal
>> is worth discussing by actually giving us an example that we can
>> discuss. So far, this thread has had nothing but toy examples (and
>> bogoexamples that prove nothing beyond that the author knows how to
>> mess with Python - fun, but not a strong argument on either side).
>> Give us some real meat to work with, instead of these drips of
>> tantalizing blood.
>
> What a strange request. Whether or not something is worth discussing
> is a personal judgement. So there can be no proof of such a thing.
> I would say: judge for yourself and act accordingly.

Plonk.

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

Re: Suggestion: make sequence and map interfaces more similar

[Antoon Pardon]

Op 31-03-16 om 13:57 schreef Chris Angelico:
> Okay. I'll put a slightly different position: Prove that your proposal
> is worth discussing by actually giving us an example that we can
> discuss. So far, this thread has had nothing but toy examples (and
> bogoexamples that prove nothing beyond that the author knows how to
> mess with Python - fun, but not a strong argument on either side).
> Give us some real meat to work with, instead of these drips of
> tantalizing blood.

What a strange request. Whether or not something is worth discussing
is a personal judgement. So there can be no proof of such a thing.
I would say: judge for yourself and act accordingly.

-- 
Antoon

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

Re: Suggestion: make sequence and map interfaces more similar

[Jussi Piitulainen]

Marko Rauhamaa writes:

> Chris Angelico wrote:
>
>> Okay. I'll put a slightly different position: Prove that your
>> proposal is worth discussing by actually giving us an example that we
>> can discuss.
>
> Sorry for missing most of the arguments here, but if you are talking
> about treating lists as special cases of dicts, I have occasionally
> instinctively wanted something like this:
>
> >>> fields = [ "x", "y", "z" ]
> >>> selector = (1, 1, 0)
> >>> list(map(fields.get, selector))
> Traceback (most recent call last):
> File "", line 1, in 
> AttributeError: 'list' object has no attribute 'get'

operator.itemgetter(*selector)(fields) # ==> ('y', 'y', 'x')

> analogously with:
>
> >>> field_dict = { 0: "x", 1: "y", 2: "z" }
> >>> list(map(field_dict.get, selector))
> ['y', 'y', 'x']

operator.itemgetter(*selector)(field_dict) # ==> ('y', 'y', 'x')

It's not quite the same but it's close and it works the same for
strings, lists, dicts, ...
-- 
https://mail.python.org/mailman/listinfo/python-list

Re: Suggestion: make sequence and map interfaces more similar

[Marco Sulla via Python-list]

I want also to add that we are focusing on sequences, but my proposal
is also to make map interface more similar, introducing a vdict type
that iterates over values, and this will be for me really more
practical. PEP 234 (  http://legacy.python.org/dev/peps/pep-0234/ )
never convinced me. Van Rossum said:

> The symmetry between "if x in y" and "for x in y"
> suggests that it should iterate over keys.  This symmetry has been
> observed by many independently and has even been used to "explain"
> one using the other.  This is because for sequences, "if x in y"
> iterates over y comparing the iterated values to x.

This argument will never convinced me. It's a lot more practical (as
Van Rossum admitted further) to iterate over values by default on
maps. Furthermore I see much more symmetry between keys of maps and
indexes of sequences, so it's much more natural to make map iteration
over values by default, as for sequences. This is why I proposed a
vdict.


On 31 March 2016 at 14:30, Mark Lawrence via Python-list
 wrote:
> Note that dict also supports
> __getitem__() and __len__(), but is considered a mapping rather than a
> sequence because the lookups use arbitrary immutable keys rather than
> integers.

Thank you for confirming for what I already wrote and quoted, but I suppose you
missed some of my previous messages, my dear friend.
-- 
https://mail.python.org/mailman/listinfo/python-list

Re: Suggestion: make sequence and map interfaces more similar

[Chris Angelico]

On Thu, Mar 31, 2016 at 11:36 PM, Marko Rauhamaa  wrote:
> Chris Angelico :
>
>> On Thu, Mar 31, 2016 at 10:22 PM, Antoon Pardon
>>  wrote:
>> Okay. I'll put a slightly different position: Prove that your proposal
>> is worth discussing by actually giving us an example that we can
>> discuss.
>
> Sorry for missing most of the arguments here, but if you are talking
> about treating lists as special cases of dicts, I have occasionally
> instinctively wanted something like this:
>
> >>> fields = [ "x", "y", "z" ]
> >>> selector = (1, 1, 0)
> >>> list(map(fields.get, selector))
> Traceback (most recent call last):
> File "", line 1, in 
> AttributeError: 'list' object has no attribute 'get'
>
> Or course, I could:
>
> >>> list(map(fields.__getitem__, selector))
> ['y', 'y', 'x']
>
> but that would abuse a dunder method. So I will need to:
>
> >>> list(map(lambda i: fields[i], selector))
> ['y', 'y', 'x']
>
> or (most likely):
>
> >>> new_fields = []
> >>> for i in selector:
> ...   new_fields.append(fields[i])
> ...
> >>> new_fields
> ['y', 'y', 'x']
>
>
> This tiny problem of mine could be remedied by adding a get method to
> lists.

Or, even more likely and even more Pythonic:

>>> [fields[i] for i in selector]
['y', 'y', 'x']

As soon as you get past the easy and obvious case of an existing
function, filter and map quickly fall behind comprehensions in utility
and readability.

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

Re: Suggestion: make sequence and map interfaces more similar

[Marko Rauhamaa]

Chris Angelico :

> On Thu, Mar 31, 2016 at 10:22 PM, Antoon Pardon
>  wrote:
> Okay. I'll put a slightly different position: Prove that your proposal
> is worth discussing by actually giving us an example that we can
> discuss.

Sorry for missing most of the arguments here, but if you are talking
about treating lists as special cases of dicts, I have occasionally
instinctively wanted something like this:

>>> fields = [ "x", "y", "z" ]
>>> selector = (1, 1, 0)
>>> list(map(fields.get, selector))
Traceback (most recent call last):
File "", line 1, in 
AttributeError: 'list' object has no attribute 'get'

analogously with:

>>> field_dict = { 0: "x", 1: "y", 2: "z" }
>>> list(map(field_dict.get, selector))
['y', 'y', 'x']

Or course, I could:

>>> list(map(fields.__getitem__, selector))
['y', 'y', 'x']

but that would abuse a dunder method. So I will need to:

>>> list(map(lambda i: fields[i], selector))
['y', 'y', 'x']

or (most likely):

>>> new_fields = []
>>> for i in selector:
...   new_fields.append(fields[i])
...
>>> new_fields
['y', 'y', 'x']


This tiny problem of mine could be remedied by adding a get method to
lists.


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

Re: Suggestion: make sequence and map interfaces more similar

[Mark Lawrence via Python-list]

On 31/03/2016 12:58, Marco Sulla via Python-list wrote:

On 31 March 2016 at 04:40, Steven D'Aprano  wrote:

Enough of the hypothetical arguments about what one could do or might do.
Let's see a concrete example of actual real world code used in production,
not a mickey-mouse toy program, where it is desirable that adding or
deleting one key will modify the rest of the keys in the mapping.



1. the example was for confuting your assertion that an implementation
of sequences as extended classes of maps violate the map contract.
2. I already linked a real-world example previously. Google it and you
can find tons of examples like that.


On 31 March 2016 at 04:44, Steven D'Aprano  wrote:

for a, b in zip(spam, eggs):
 # do some stuff, sometimes assign x[a] or b[a] or who knows what?


Does this mean that "lists, dicts and zip" should all support the same
interface?


I do not understand what you mean with this example. A zip object is
not a sequence nor a map. My definition of sequences as "ordered maps
with integer keys that start from zero and have no gaps" is perfectly
valid as I demonstrated to you, while zip objects have nothing in
common with sequences and maps, apart the fact they are all iterables.



The definition of sequence is given here 
https://docs.python.org/3/glossary.html#term-sequence.



An iterable which supports efficient element access using integer 
indices via the __getitem__() special method and defines a __len__() 
method that returns the length of the sequence. Some built-in sequence 
types are list, str, tuple, and bytes. Note that dict also supports 
__getitem__() and __len__(), but is considered a mapping rather than a 
sequence because the lookups use arbitrary immutable keys rather than 
integers.


The collections.abc.Sequence abstract base class defines a much 
richer interface that goes beyond just __getitem__() and __len__(), 
adding count(), index(), __contains__(), and __reversed__(). Types that 
implement this expanded interface can be registered explicitly using 
register().



As this is a Python list the above definition clearly takes priority 
over your definition, so can you please take this discussion offline, 
thanks.


--
My fellow Pythonistas, ask not what our language can do for you, ask
what you can do for our language.

Mark Lawrence

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

[issue26492] Exhausted array iterator should left exhausted

[Serhiy Storchaka]

Changes by Serhiy Storchaka :


--
resolution:  -> fixed
stage: patch review -> 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

[issue26494] Double deallocation on iterator exhausting

[Serhiy Storchaka]

Changes by Serhiy Storchaka :


--
assignee:  -> serhiy.storchaka
resolution:  -> fixed
stage: patch review -> 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

Re: Suggestion: make sequence and map interfaces more similar

[Marco Sulla via Python-list]

On 31 March 2016 at 04:40, Steven D'Aprano  wrote:
> Enough of the hypothetical arguments about what one could do or might do.
> Let's see a concrete example of actual real world code used in production,
> not a mickey-mouse toy program, where it is desirable that adding or
> deleting one key will modify the rest of the keys in the mapping.


1. the example was for confuting your assertion that an implementation
of sequences as extended classes of maps violate the map contract.
2. I already linked a real-world example previously. Google it and you
can find tons of examples like that.


On 31 March 2016 at 04:44, Steven D'Aprano  wrote:
> for a, b in zip(spam, eggs):
> # do some stuff, sometimes assign x[a] or b[a] or who knows what?
>
>
> Does this mean that "lists, dicts and zip" should all support the same
> interface?

I do not understand what you mean with this example. A zip object is
not a sequence nor a map. My definition of sequences as "ordered maps
with integer keys that start from zero and have no gaps" is perfectly
valid as I demonstrated to you, while zip objects have nothing in
common with sequences and maps, apart the fact they are all iterables.
-- 
https://mail.python.org/mailman/listinfo/python-list

Re: Suggestion: make sequence and map interfaces more similar

[Chris Angelico]

On Thu, Mar 31, 2016 at 10:22 PM, Antoon Pardon
 wrote:
> Op 31-03-16 om 12:36 schreef Steven D'Aprano:
>> On Thu, 31 Mar 2016 06:52 pm, Antoon Pardon wrote:
>>
>>> it is your burden to argue that problem.
>> No it isn't. I don't have to do a thing. All I need to do is sit back and
>> wait as this discussion peters off into nothing. The burden isn't on me to
>> justify the status quo. The burden is on those who want to make this change
>> to justify the change, because if you don't, the status quo stays exactly
>> the same.
>
> Sure that is all very well if you stay out of the discussion, or limit
> your contribution to mentioning that in your opinion that this is a
> very low priority. I have no problem with that. But if you begin to
> argue that the proposal has flaws and you argue against it then it
> is your intellectual responsibility to support your arguments.
>
> There is a difference between, (1) this proposal is flawed and (2)I
> don't think this is important enough. Starting with the first and then
> when pressed to support it, retreating to the second is not fair.
>

Okay. I'll put a slightly different position: Prove that your proposal
is worth discussing by actually giving us an example that we can
discuss. So far, this thread has had nothing but toy examples (and
bogoexamples that prove nothing beyond that the author knows how to
mess with Python - fun, but not a strong argument on either side).
Give us some real meat to work with, instead of these drips of
tantalizing blood.

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

ANN: python_to_coffeescript 0.1

[Edward K. Ream]

py2cs.py 0.1 is now available on github
.

This script makes a coffeescript  (.coffee) file
in the output directory for each source file listed on the command line
(wildcard file names are supported). This script never creates directories
automatically, nor does it overwrite .coffee files unless the --overwrite
command-line option is in effect.

This script merely converts python syntax to the roughly equivalent
coffeescript syntax. It knows nothing about coffeescript semantics. It is
intended *only* to help start creating coffeescript code from an existing
python code base.

This script already does much of the grunt work of converting python to
coffeescript. The script processes itself without error, but coffeescript
itself complains about some results
​.​

​Edward​ K. Ream
March 31, 2016
--
Edward K. Ream: edream...@gmail.com Leo: http://leoeditor.com/
--
-- 
https://mail.python.org/mailman/listinfo/python-announce-list

Support the Python Software Foundation:
http://www.python.org/psf/donations/

ANN: make_stub_files 0.1

[Edward K. Ream]

m
​ake_stub_files.py ​
0.1 is now available here .

This script eliminates much of the drudgery of creating python stub (.pyi)
 from python source
files. This script should encourage more people to use mypy. Stub files can
be used by people who use Python 2.x code bases.

This script makes a stub (.pyi) file in the output directory for each
source file listed on the command line (wildcard file names are supported).
This script never creates directories automatically, nor does it overwrite
stub files unless the --overwrite command-line option is in effect.

GvR says,

We actually do have a stub generator
 as part of
mypy now (it has a few options) but yours has the advantage of providing a
way to tune the generated signatures...This allows for a nice iterative way
of developing stubs.

The script does no type inference. Instead, the user supplies *patterns* in
a configuration file. The script matches these patterns to:

   1.

   The names of arguments in functions and methods and
   2.

   The text of *return expressions*. Return expressions are the actual text
   of whatever follows the "return" keyword. The script removes all comments
   in return expressions and converts all strings to "str". This preprocessing
   greatly simplifies pattern matching.

For example, given the method:

def foo(self, i, s):
if i:
return "abc" # a comment
else:
return s

and the patterns:

i: int
s: str

the script produces the stub:

def foo(i: int, s: str) --> str: ...

Edward K. Ream
March 31, 2016
--
Edward K. Ream: edream...@gmail.com Leo: http://leoeditor.com/
--
-- 
https://mail.python.org/mailman/listinfo/python-announce-list

Support the Python Software Foundation:
http://www.python.org/psf/donations/