Re: Proposed new syntax

[Rustom Mody]

On Monday, August 14, 2017 at 4:26:06 AM UTC+5:30, Gregory Ewing wrote:
> Steve D'Aprano wrote:
> 
> > Python's comprehensions are inspired by Haskell's, but we made different 
> > choices
> > than they did: we make the fact that a comprehension is a loop over values
> > explicit, rather than implicit, and we use words instead of cryptic symbols.
> 
> The presence of the word "for" in the comprehension syntax doesn't
> by itself imply that the values are generated by a sequential loop.
> 
> Comprehensions in Python are intended to be read declaratively.
> The definition in terms of an expansion into nested loops may

Thanks for speaking up Greg [Creator of comprehensions in python 2??]


Here's a bunch of different ways in which a mapping comprehension could be 
implemented:

def sq(x): return x*x
Just a trivial example

def simple(f, l):
r = []
for i in range(0,len(l)):
r.append(f(l[i]))
return r

def backwards(f,l):
r = []
for i in range(len(l)-1,-1,-1):
r.insert(0,f(l[i]))
return r

def randmap(f,l):
""" Map in random order """
from random import shuffle
r = []
index = list(range(0,len(l)))
shuffle(index)

r = [None] * len(l)
for i in index:
r[i] = f(l[i])
return r


def inplace(f, l, lb, le, res): #, rb):
""" Helper function: Maps subslice (lb,le) of input l onto (into) output 
res, with
subslice rb,re"""
for i in range(lb,le):
res[i] = f(l[i])
return None # Side-effecting into res

def parprequel0(f,l):
"""Illustrative trivial prequel to parallelizing version"""
r = [None] * len(l)
inplace(f,l,0,len(l),r)
return r

def parprequel1(f,l):
"""Illustrative prequel to parallelizing version
with 2-way split"""
r = [None] * len(l)
inplace(f,l, 0, len(l)//2, r)
inplace(f,l, len(l)//2, len(l),r)
return r

def par(f,l):
"""Illustrative prequel to parallelizing version
with 2-way split"""
from threading import Thread
r = [None] * len(l)
t1 = Thread(target=inplace, args = (f,l, 0, len(l)//2, r))
t2 = Thread(target=inplace, args = (f,l, len(l)//2, len(l),r))
t1.start()
t2.start()
t1.join()
t2.join()
return r
-- 
https://mail.python.org/mailman/listinfo/python-list

ActiveState recipes now on github

[breamoreboy]

FYI - please see 
https://www.activestate.com/blog/2017/08/code-recipes-now-github-5000-recipes-python-perl-ruby-and-more

Kindest regards.

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

Re: data ecosystem

[Rustom Mody]

On Sunday, August 13, 2017 at 6:04:42 AM UTC+5:30, Man with No Name wrote:
> So
> 
> I've an idea to make use of python's unique environment (>>>) to form a 
> peer-to-peer object-sharing ecosystem.
> 
> Just pie-in-the-sky brainstorming...
> 
> When a programmer (or object-user) starts up the python environment, the 
> environment can check for an internet connection and if present connect to a 
> central "name service" to provide a list of trusted peers which will form a 
> back-end, networked, data-object ecosystem.
> 
> What syntax?
> 
> Well, Mr. Tim Peters seemed to have an idea with namespaces 
> (~/modules/doctest.py).  Namespaces could form an ontology (or "folksonomy") 
> of objects (visualization, networking, database templates, applications, 
> etc.) based on a tree data structure, probably and be accessed by some method 
> such as __namespace__.globals.networking.www.myscrapeobject or some similar 
> syntax.
> 
> The namespace could be a global, synchronized object repository as well as 
> holding local copies.  

I ‘Mark’ the piquant point that the ‘Man with No Name’ wishes to suggest 
global namespaces 

On a more serious note:
REST uses URLs as (syntax for) RPC

(which above follows respectable industry standard called 
ASS: Alphabet Soup Simplistified
)
-- 
https://mail.python.org/mailman/listinfo/python-list

Re: Proposed new syntax

[Steve D'Aprano]

On Mon, 14 Aug 2017 08:55 am, Gregory Ewing wrote:

> Steve D'Aprano wrote:
> 
>> Python's comprehensions are inspired by Haskell's, but we made different
>> choices than they did: we make the fact that a comprehension is a loop over
>> values explicit, rather than implicit, and we use words instead of cryptic
>> symbols.
> 
> The presence of the word "for" in the comprehension syntax doesn't
> by itself imply that the values are generated by a sequential loop.
> Comprehensions in Python are intended to be read declaratively.

Where is that documented?

Why not use a declarative syntax, like "select where", instead of a procedural
syntax, if the intention is to read them declaratively?


> The definition in terms of an expansion into nested loops may
> imply that if you take it absolutely literally, but when I
> devised that expansion I only meant it as a way of defining
> the result -- I didn't intend the equivalence to extend to side
> effects.

Oh, you're to blame for that expansion are you? :-)

The core devs now take it literally: Nick and (if I remember correctly) Guido
have commented that any future expansions to comprehension syntax must fit into
that nested block expansion.

In any case, whatever your intention, that equivalence *does* extend to side
effects, and it applies to generator expressions as well as comprehensions.

I wish that we had standardised on the term "generator comprehension" instead,
to emphasise that generator expressions and comprehensions share the same
syntax, the same implementation, and the same order of side-effects.

(There was a time that list comps and gen expressions had different
implementations, and consequently list comps accidentally exposed their loop
variable while gen exprs didn't, but that's been fixed in Python 3.)

I would argue that in a language like Python that allows side-effects, such a
procedural approach should be mandatory: the alternative is that code including
comprehensions would be non-deterministic. While it is conceivable that the
list comprehension:

[x for x in seq]

could generate its values in arbitrary order, that does not apply to generator
expressions, set comprehensions or dict expressions:

(x for x in seq)
{x for x in seq}
{x:None for x in seq}

- Generator expressions have to yield their values in the same 
  order as the input from seq provides them;

- set and dict comprehensions have to deal with collisions, 
  in which case the last key seen wins. If they were declarative,
  there would be no way to reason about which key was seen last.


Given the expectation that generator expressions and all three kinds of
comprehension should operate the same way, we have no choice but to read them
procedurally as a for-loop.


 

-- 
Steve
“Cheer up,” they said, “things could be worse.” So I cheered up, and sure
enough, things got worse.

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

Re: data ecosystem

[Chris Angelico]

On Mon, Aug 14, 2017 at 10:42 AM, Steve D'Aprano
 wrote:
> On Mon, 14 Aug 2017 07:39 am, Man with No Name wrote:

I've no idea who you're responding to. Those posts aren't coming
through at my end.

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

Re: data ecosystem

[Steve D'Aprano]

On Mon, 14 Aug 2017 07:39 am, Man with No Name wrote:


>> Pretty much any programming language *could* have an interactive interpreter,
>> if somebody spent the effort to build one.
> 
> Are you sure?

Yes.

>> The thing about re-useable software components is that it turns out that most
>> of them aren't that re-useable.
> 
> Exactly.  I think you're onto something, this re-useability thing.  That is
> why I argue that the goals of re-useability can be realized with making all
> objects have a standard API.

That whizzing noise you heard was my point flying just over your head.


>> > I quite like the idea that vigil (see github)
>> 
>> What is vigil, and what does it have to do with github?
> 
> It's a software project over at... github,.

You should have said, and provided a link.



>> What makes you think that "standardizing objects across the ecosystem" is
>> something that should be done?
> 
> It makes it easier to reuse code just as your high-level language of choice
> allows you to standardize the way you access the underlying machine.  Get it? 

There's only a limited number of underlying machines. The programming ecosystem
has an effectively infinite number of problems to solve. Being forced to use
your solution to some problem does not necessarily make it easier for my to
solve some slightly different problem. Hence my point about software
re-useability.


> It's pretty cool.  There are exabytes of data out there, most of it pretty
> categorizable into probably log(N) categories.

Oh, it's "cool" is it? Then we should definitely do whatever is "cool" this
week.

By the way... are you aware that OOP is just one programming paradigm out of
many, and despite the hype that it was going to solve all our programming
problems, it has turned out to be far from the silver bullet that proponents
claimed it would be?


>> Such a programming monoculture would be a
>> terrible mistake.
> 
> Hmmm.  Is python becoming a "programming monoculture"?

No.

> Shouldn't you use some C and Haskell code in there too?

How do you know that I don't?

Plenty of people use C, Fortran, Java, R and Julia code in their Python
projects. If you've ever used numpy, you're using C or Fortran. I don't know
about Haskell -- I suppose somebody has built a Python/Haskell interface by
now, but I don't know for sure.


> Thanks for your educated input.

I detect a note of sarcasm. You did ask for our opinion -- if you had only
wanted people who agreed with you to answer, you should have said so.




-- 
Steve
“Cheer up,” they said, “things could be worse.” So I cheered up, and sure
enough, things got worse.

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

[issue31196] Blank line inconsistency between InteractiveConsole and standard interpreter

[Tom Viner]

Changes by Tom Viner :


--
nosy: +tomviner

___
Python tracker 

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

[issue31193] re.IGNORECASE strips combining character from lower case of LATIN CAPITAL LETTER I WITH DOT ABOVE

[Tom Viner]

Changes by Tom Viner :


--
nosy: +tomviner

___
Python tracker 

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

Re: Proposed new syntax

[Gregory Ewing]

Steve D'Aprano wrote:


Python's comprehensions are inspired by Haskell's, but we made different choices
than they did: we make the fact that a comprehension is a loop over values
explicit, rather than implicit, and we use words instead of cryptic symbols.


The presence of the word "for" in the comprehension syntax doesn't
by itself imply that the values are generated by a sequential loop.

Comprehensions in Python are intended to be read declaratively.
The definition in terms of an expansion into nested loops may
imply that if you take it absolutely literally, but when I
devised that expansion I only meant it as a way of defining
the result -- I didn't intend the equivalence to extend to side
effects.

However, Steve's other points remain -- Python's overall style
is one of explicitness and clarity. The proposed extensions
don't fit into that style.

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

[issue26669] time.localtime(float("NaN")) does not raise a ValueError on all platforms

[Roundup Robot]

Changes by Roundup Robot :


--
pull_requests: +3127

___
Python tracker 

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

Re: Proposed new syntax

[Tim Chase]

On 2017-08-14 00:36, Steve D'Aprano wrote:
> Python's comprehensions are inspired by Haskell's, but we made
> different choices than they did: we make the fact that a
> comprehension is a loop over values explicit, rather than implicit,
> and we use words instead of cryptic symbols.

I keep wanting to like Haskell for some of the concepts &
optimizations it can do, but the whole "words instead of cryptic
symbols" readability thing keeps me coming back to Python.

-tkc





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

[issue31159] Doc: Language switch can't switch on specific cases

[STINNER Victor]

STINNER Victor added the comment:

To choose the langague, see what Wikipedia does: Wikipedia EN displays
"Français", no?

--

___
Python tracker 

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

[issue31149] Add Japanese to the language switcher

[STINNER Victor]

STINNER Victor added the comment:


New changeset fe8d9dc479a96ef490034107e7d4a6228b4be140 by Victor Stinner 
(Julien Palard) in branch '2.7':
bpo-31159: fix language switch regex on unknown yet built languages. … (#3051) 
(#3081)
https://github.com/python/cpython/commit/fe8d9dc479a96ef490034107e7d4a6228b4be140


--

___
Python tracker 

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

[issue31159] Doc: Language switch can't switch on specific cases

[STINNER Victor]

STINNER Victor added the comment:


New changeset fe8d9dc479a96ef490034107e7d4a6228b4be140 by Victor Stinner 
(Julien Palard) in branch '2.7':
bpo-31159: fix language switch regex on unknown yet built languages. … (#3051) 
(#3081)
https://github.com/python/cpython/commit/fe8d9dc479a96ef490034107e7d4a6228b4be140


--

___
Python tracker 

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

[issue31196] Blank line inconsistency between InteractiveConsole and standard interpreter

[Malcolm Smith]

New submission from Malcolm Smith:

The standard interpreter is more eager to give an error on incomplete input, 
while the InteractiveConsole will keep on prompting for more:

Python 3.5.3 (default, Apr 10 2017, 07:53:16)  [GCC 6.3.0 64 bit (AMD64)] on 
win32
Type "help", "copyright", "credits" or "license" for more information.
>>> try:
...
  File "", line 2

^
IndentationError: expected an indented block
>>> import code
>>> code.interact()
Python 3.5.3 (default, Apr 10 2017, 07:53:16)  [GCC 6.3.0 64 bit (AMD64)] on 
win32
Type "help", "copyright", "credits" or "license" for more information.
(InteractiveConsole)
>>> try:
...
...
...
...

The InteractiveConsole isn't totally wrong here, because after all, a blank 
line in this position is syntactically correct. But the inconsistency is 
confusing.

--
components: Library (Lib)
messages: 300230
nosy: Malcolm Smith
priority: normal
severity: normal
status: open
title: Blank line inconsistency between InteractiveConsole and standard 
interpreter
type: behavior
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

[issue31158] test_pty: test_basic() fails randomly on Travis CI

[Xavier de Gaye]

Changes by Xavier de Gaye :


--
nosy: +xdegaye

___
Python tracker 

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

[issue31182] Suggested Enhancements to zipfile & tarfile command line interfaces

[Steve Barnes]

Changes by Steve Barnes :


--
pull_requests: +3126

___
Python tracker 

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

[issue31147] a suboptimal check in list_extend()

[Oren Milman]

Oren Milman added the comment:

thank you for the elaborate reply :)

do you feel the same about changing the check to
(Py_SIZE(self) < (self->allocated >> 1)) ?

--

___
Python tracker 

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

[issue31186] Support heapfix() and heapremove() APIs in heapq module

[Rajath Agasthya]

Rajath Agasthya added the comment:

And yes, both of these methods do take index as the argument as shown in my 
patch file. I should've probably specified that. 

The signatures are:

heapfix(heap, pos)
heapremove(heap, pos)

--

___
Python tracker 

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

[issue31186] Support heapfix() and heapremove() APIs in heapq module

[Rajath Agasthya]

Rajath Agasthya added the comment:

> The only hacks around that I could think of required a more complex kind of 
> heap; e.g., restricting heap items to objects usable as dict keys, using a 
> hidden dict to map heap items to their current index, and fiddling all the 
> heap operations to keep that dict up to date.

Actually, this is *exactly* how I ended up thinking about this feature. I was 
using a separate dict to track the index at which objects are inserted in a 
heap, using the index to make updates to heap directly, and fixing the heap by 
calling heapify() every time which was slightly costly. Maybe I chose the wrong 
data structure for the problem, but constant time getMin() operation was 
crucial for me. And I didn't really care if inserts (or updates) were costlier. 

But I completely agree that it's a niche use case and I understand if we don't 
want to support this :)

--

___
Python tracker 

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

[issue31195] Make any() and all() work with async generators

[Yury Selivanov]

Yury Selivanov added the comment:

> Or am I missing something subtle here?

We'll need to make any() and all() coroutines.  Not simple coroutines though, 
but weird "hybrid" functions that preserve the old semantics + implement async 
stuff.

I don't think this is a very good idea.  Maybe we should think about 
"asyncitertools" package with functions like "anext", "aiter", "async_all", 
"async_chain", etc.

--

___
Python tracker 

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

[issue31186] Support heapfix() and heapremove() APIs in heapq module

[Tim Peters]

Tim Peters added the comment:

@Rajath, I suspect Raymond may have been bamboozled because your suggested 
`heapfix()` and `heapremove()` didn't appear to take any arguments.  If the 
index is a required argument, then these are O(log N) operations.

I thought about adding them years ago, but didn't find a _plausible_ use case:  
the index at which a specific heap item appears is pretty much senseless, and 
typically varies over a heap's lifetime.  So how does the user know _which_ 
index to pass?  A linear search over the underlying list to find the index of a 
specific heap item is probably unacceptable.

The only hacks around that I could think of required a more complex kind of 
heap; e.g., restricting heap items to objects usable as dict keys, using a 
hidden dict to map heap items to their current index, and fiddling all the heap 
operations to keep that dict up to date.

So, in the absence of an obvious way to proceed, I gave up :-)

--
nosy: +tim.peters

___
Python tracker 

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

[issue31195] Make any() and all() work with async generators

[Brett Cannon]

New submission from Brett Cannon:

It would be great if I could do something like:

  if any(x for async x in aiter()): ...

But as of right now, any() complains that "TypeError: 'async_generator' object 
is not iterable". I would assume that any() and all() could be updated to look 
for __aiter__() instead of just __iter__() and do the right thing in either 
case? Or am I missing something subtle here?

--
components: Library (Lib)
messages: 300224
nosy: brett.cannon, giampaolo.rodola, haypo, yselivanov
priority: normal
severity: normal
status: open
title: Make any() and all() work with async generators
versions: Python 3.7

___
Python tracker 

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

[issue31186] Support heapfix() and heapremove() APIs in heapq module

[Rajath Agasthya]

Rajath Agasthya added the comment:

Thanks, Raymond. I think it's fair comment, but I'm not sure which operation is 
O(n) though. FWIW, Go supports these operations 
(https://golang.org/pkg/container/heap/), so the usage is there.

--

___
Python tracker 

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

[issue31194] Inconsistent __repr__s for _collections objects

[Serhiy Storchaka]

Changes by Serhiy Storchaka :


--
nosy: +rhettinger, serhiy.storchaka

___
Python tracker 

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

[issue31194] Inconsistent __repr__s for _collections objects

[Dan Snider]

New submission from Dan Snider:

With the new C implementation of collections.OrderedDict, its repr correctly 
uses the subclass's name, unlike deque and defaultdict.

class Thing(_collections.OrderedDict):
pass
>>> Thing()
Thing([])

class Thing(_collections.deque):
pass
>>> Thing()
deque([])

--
components: Library (Lib)
messages: 300222
nosy: bup
priority: normal
severity: normal
status: open
title: Inconsistent __repr__s for _collections objects
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

Re: Recent Spam problem

[Grant Edwards]

On 2017-08-13, J. Clarke  wrote:
> In article , 
> skybuck2...@hotmail.com says...
>> 
>> I see two solutions:

> It would be really nice if someone could convince radical Islam that 
> spammers are offensive to Mohammed.  After a few of them got hunted down 
> and blown up, the rest might take the hint.

It would be really nice if someone could convice people to stopped
replying to spam posted from googlegroups.  That way people who've
taken the common-sense approach and plonked all postings from google
groups wouldn't have to see them.

--
Grant



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

[issue31161] Only check for print and exec parentheses cases for SyntaxError, not subclasses

[Martijn Pieters]

Changes by Martijn Pieters :


--
pull_requests: +3125

___
Python tracker 

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

[issue31161] Only check for print and exec parentheses cases for SyntaxError, not subclasses

[Martijn Pieters]

Changes by Martijn Pieters :


--
pull_requests: +3124

___
Python tracker 

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

[issue31161] Only check for print and exec parentheses cases for SyntaxError, not subclasses

[Martijn Pieters]

Martijn Pieters added the comment:

Disregard my last message, I misread Serhiy's sentence (read 'correct' for 
'incorrect').

--

___
Python tracker 

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

[issue31161] Only check for print and exec parentheses cases for SyntaxError, not subclasses

[Martijn Pieters]

Martijn Pieters added the comment:

This does not increase clarity. It creates confusion.

There are two distinct syntax errors, and they should be reported separately, 
just like `print "abc" 42` is two syntax errors; you'll hear about the second 
one once the first one is fixed.

--

___
Python tracker 

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

Re: Proposed new syntax

[Steve D'Aprano]

On Sat, 12 Aug 2017 01:02 am, Ian Kelly wrote:

> On Thu, Aug 10, 2017 at 11:45 PM, Steve D'Aprano
>  wrote:

>> Comprehension syntax makes the sequential loop explicit: the loop is right
>> there in the syntax:
>>
>> [expr for x in iterable]
> 
> This is a peculiarity of Python. 

Yes? We're talking about Python? I haven't accidentally been posting to
comp.lang.anything-but-python have I? *wink*

I am not referring to syntax from other languages. (One wonders what a list
comprehension in Whitespace would look like...) We're talking about Python,
which prefers explicit English-like executable pseudo-code over implicit
cryptic mathematical symbolic expressions.

Python prefers to be explicit, rather than implicit: that's why purely
functional idioms like map, filter and reduce are less idiomatic than
comprehensions.

But for the record, this is not a peculiarity of Python by any means. I count at
least a dozen other languages which use an explicit "for" in their
comprehension syntax:

Boo, Ceylon, Clojure, CoffeeScript, Common Lisp, Cobra, Elixir, F#, Mozilla's
Javascript, Julia, Perl6, Racket and Scala.

https://en.wikipedia.org/wiki/Comparison_of_programming_languages_%28list_comprehension%29

And very possibly the first language with comprehensions, SETL (from 1969),
used "forall":

[n in [2..N] | forall m in {2..n - 1} | n mod m > 0]

https://en.wikipedia.org/wiki/List_comprehension#History


> Here's a list comprehension in 
> Haskell, which has supported them since version 1.0 in 1990, much
> longer than Python:
> 
> [x * 2 | x <- L, x * x > 3]

Sure. In Haskell, comprehensions are *implicit* loops, rather than explicit like
in Python.

Python's comprehensions are inspired by Haskell's, but we made different choices
than they did: we make the fact that a comprehension is a loop over values
explicit, rather than implicit, and we use words instead of cryptic symbols.



-- 
Steve
“Cheer up,” they said, “things could be worse.” So I cheered up, and sure
enough, things got worse.

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

Re: wrote a commodore-64 emulator using just Python

[Larry Martell]

On Sun, Aug 13, 2017 at 9:50 AM, Irmen de Jong  wrote:
> Hi,
>
> As another experiment with using just tkinter for graphics, this time I 
> created a
> Commodore-64 emulator. You can find it here https://github.com/irmen/pyc64
> You only need the pillow library to be able to run this. I guess most people 
> have that
> one already anyway.
>
> It works pretty well :)   (although having some slight speed/timing issues on 
> windows)
>
> Now, it's not a "true" emulator: obviously it doesn't simulate the C64 on a 
> hardware
> level. It does however implement enough to load and run simple basic programs 
> that can
> show interesting PETSCII pictures by manipulating the colors and characters 
> on the screen.
>
> And perhaps you can think of doing some other silly things because part of 
> the BASIC
> dialect is just executed using eval() in python. What about hooking this up 
> as a ssh
> client to get access to your server in a way nobody thought possible? :-P
> There's also https://github.com/mnaberez/py65 so... possibilities?
>
>
> Fun fact: emulator source is smaller than 64KB

Damn! I should have saved my Cave Of The Word Wizard floppies.
-- 
https://mail.python.org/mailman/listinfo/python-list

Re: wrote a commodore-64 emulator using just Python

[Larry Martell]

On Sun, Aug 13, 2017 at 9:50 AM, Irmen de Jong  wrote:
> Hi,
>
> As another experiment with using just tkinter for graphics, this time I 
> created a
> Commodore-64 emulator. You can find it here https://github.com/irmen/pyc64
> You only need the pillow library to be able to run this. I guess most people 
> have that
> one already anyway.
>
> It works pretty well :)   (although having some slight speed/timing issues on 
> windows)
>
> Now, it's not a "true" emulator: obviously it doesn't simulate the C64 on a 
> hardware
> level. It does however implement enough to load and run simple basic programs 
> that can
> show interesting PETSCII pictures by manipulating the colors and characters 
> on the screen.
>
> And perhaps you can think of doing some other silly things because part of 
> the BASIC
> dialect is just executed using eval() in python. What about hooking this up 
> as a ssh
> client to get access to your server in a way nobody thought possible? :-P
> There's also https://github.com/mnaberez/py65 so... possibilities?
>
>
> Fun fact: emulator source is smaller than 64KB
>
> Cheers
> Irmen.
> --
> https://mail.python.org/mailman/listinfo/python-list
-- 
https://mail.python.org/mailman/listinfo/python-list

wrote a commodore-64 emulator using just Python

[Irmen de Jong]

Hi,

As another experiment with using just tkinter for graphics, this time I created 
a
Commodore-64 emulator. You can find it here https://github.com/irmen/pyc64
You only need the pillow library to be able to run this. I guess most people 
have that
one already anyway.

It works pretty well :)   (although having some slight speed/timing issues on 
windows)

Now, it's not a "true" emulator: obviously it doesn't simulate the C64 on a 
hardware
level. It does however implement enough to load and run simple basic programs 
that can
show interesting PETSCII pictures by manipulating the colors and characters on 
the screen.

And perhaps you can think of doing some other silly things because part of the 
BASIC
dialect is just executed using eval() in python. What about hooking this up as 
a ssh
client to get access to your server in a way nobody thought possible? :-P
There's also https://github.com/mnaberez/py65 so... possibilities?


Fun fact: emulator source is smaller than 64KB

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

[issue31193] re.IGNORECASE strips combining character from lower case of LATIN CAPITAL LETTER I WITH DOT ABOVE

[David MacIver]

New submission from David MacIver:

chr(304).lower() is a two character string - a lower case i followed by a 
combining chr(775) ('COMBINING DOT ABOVE').

The re module seems not to understand the combining character and a regex 
compiled with IGNORECASE will erroneously match a single lower case i without 
the required combining character. The attached file demonstrates this. I've 
tested this on Python 3.6.1 with my locale as ('en_GB', 'UTF-8') (I don't know 
whether that matters for reproducing this, but I know it can affect how 
lower/upper work so am including it for the sake of completeness).

The problem does not reproduce on Python 2.7.13 because on that case 
chr(304).lower() is 'i' without the combining character, so it fails earlier.

This is presumably related to #12728, but as that is closed as fixed while this 
still reproduces I don't believe it's a duplicate.

--
components: Library (Lib)
files: casing.py
messages: 300219
nosy: David MacIver
priority: normal
severity: normal
status: open
title: re.IGNORECASE strips combining character from lower case of LATIN 
CAPITAL LETTER I WITH DOT ABOVE
versions: Python 3.6
Added file: http://bugs.python.org/file47080/casing.py

___
Python tracker 

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

Re: data ecosystem

[Steve D'Aprano]

On Sun, 13 Aug 2017 10:34 am, Man with No Name wrote:

> So
> 
> I've an idea to make use of python's unique environment (>>>) to form a
> peer-to-peer object-sharing ecosystem.

Sounds perfectly awful.

By the way, Python's interactive interpreter (>>>) is hardly unique. Just off
the top of my head, I can think of Lua, Julia, Clojure, Ruby, Haskell, Erlang,
Rhino (Javascript), Scala, Boo, F# and PHP which all have either a standard
interactive interpreter, or if not standard, at least a well-known one.

Pretty much any programming language *could* have an interactive interpreter, if
somebody spent the effort to build one.


> Just pie-in-the-sky brainstorming...
> 
> When a programmer (or object-user) starts up the python environment, the
> environment can check for an internet connection and if present connect to a
> central "name service" to provide a list of trusted peers which will form a
> back-end, networked, data-object ecosystem.

The day that my Python interpreter automatically connects to a peer-to-peer
network of other people, "trusted" or not, to download code, will be the day I
stop using the Python interpreter.


[...]
> Python would be breaking new ground, I think (.NET comes perhaps the closest)
> for living up to the dream of OOP of a true re-useable object and programmer
> ecosystem.

The thing about re-useable software components is that it turns out that most of
them aren't that re-useable.


> I quite like the idea that vigil (see github) 

What is vigil, and what does it have to do with github?


> offered for two keywords that 
> would offer a very nice contract environment for trusting other objects which 
> I think will be essential for standardizing objects across the ecosystem.

What makes you think that "standardizing objects across the ecosystem" is
something that should be done? Such a programming monoculture would be a
terrible mistake.



-- 
Steve
“Cheer up,” they said, “things could be worse.” So I cheered up, and sure
enough, things got worse.

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

[issue15988] Inconsistency in overflow error messages of integer argument

[Serhiy Storchaka]

Serhiy Storchaka added the comment:

Glad to see you again Oren! Maybe first finish issue28261? It looks easier.

--

___
Python tracker 

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

[issue31187] suboptimal code in Py_ReprEnter()

[Serhiy Storchaka]

Serhiy Storchaka added the comment:

PyList_GET_SIZE(list) is cheap (especially in comparison of 
_PyDict_GetItemId(), _PyDict_SetItemId() and PyList_New()), and its tiny 
overhead can be avoided at most once per thread's lifetime. I'm sure you can't 
measure the effect of this change.

If surrounding code be modified for other reasons, may be your change could be 
applied. But it alone just makes a code churn.

--
nosy: +rhettinger, serhiy.storchaka

___
Python tracker 

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

[issue31149] Add Japanese to the language switcher

[Roundup Robot]

Changes by Roundup Robot :


--
pull_requests: +3122

___
Python tracker 

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

[issue31159] Doc: Language switch can't switch on specific cases

[Roundup Robot]

Changes by Roundup Robot :


--
pull_requests: +3123

___
Python tracker 

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

[issue31149] Add Japanese to the language switcher

[Julien Palard]

Julien Palard added the comment:

Arfrever: nice catch!

Inda: What do you think? Any preference between "日本語", "Japanese", and  "日本語 
(Japanese)"?

I personally don't like much the "日本語 (Japanese)" version, but I don't care 
much between "French" and "Français" as they're using the same alphabet.

Maybe displaying "日本語" instead of "Japanese" show more commitment into 
translations? Like displaying "Japanese" meaning "OK we translated, but not 
everything, starting by your language".

Another solution would be to translate each languages in each languages, and 
display "Anglais, Japonais, Français" in the french translation, "English, 
Japanese, French" in the english one, and so on…

I think I prefer to display languages in their own language, so "English, 
"Français", "日本語" for me.

--

___
Python tracker 

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

[issue30871] Add a "python info" command somewhere to dump versions of all dependencies

[Serhiy Storchaka]

Serhiy Storchaka added the comment:

> Sorry, version of what?

Versions of any external library. Python can be built with headers of one 
version, but dynamically load the library of other version.

For example TCL_VERSION and TK_VERSION are static versions (they should be 
equal in modern Tcl/Tk), and Tcl command "info patchlevel" returns the dynamic 
version. In the readline module _READLINE_VERSION is header version, 
_READLINE_RUNTIME_VERSION and _READLINE_LIBRARY_VERSION are runtime versions. 
In the zlib module ZLIB_VERSION is header version, ZLIB_RUNTIME_VERSION is 
runtime version.

--

___
Python tracker 

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

[issue31161] Only check for print and exec parentheses cases for SyntaxError, not subclasses

[Serhiy Storchaka]

Serhiy Storchaka added the comment:

The current traceback is incorrect. It mixes exception type and message from 
different errors.

--

___
Python tracker 

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

[issue31149] Add Japanese to the language switcher

[Arfrever Frehtes Taifersar Arahesis]

Arfrever Frehtes Taifersar Arahesis added the comment:

There is a minor inconsistency:
For French language, name in the list is displayed in French as "Français".
For Japanese language, name in the list is displayed in English as "Japanese" 
instead of in Japanese as "日本語".

Maybe it would be best to display 2 names for each non-English language? 
Example:
 "Français (French)"
 "日本語 (Japanese)"

--
nosy: +Arfrever

___
Python tracker 

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

Re: Proposed new syntax

[Marko Rauhamaa]

Glenn Linderman :

> I really don't think that "comprehension" in English, in the manner
> used for Python set manipulation, is equivalent at all to the English
> word "understand".

Correct. However, the two meanings of "comprehension" have a common
etymological ancestor. The literal meaning in Latin was "taking in",
"gathering".

Both "take in" and "gather" have similar metaphorical meanings in Modern
English, as well.


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