Re: Type annotation pitfall

[Peter Saalbrink]

I don't think this has anything to do with typing or providing type hints.
The type hint is the `: set` part, not the `= set()` part.
You can declare the type without assigning to the variable.
Indeed, as you already said, `x` is a class property here, and is shared
amongst instances of the class.
It might be a good idea to move the attribute assignment to the `__init__`
method.

In the following way, you can safely provide the type hint:

```python
class Foo:
x: set

def __init__(self, s):
self.x = set()
if s:
self.x.add(s)
```

Or, even shorter:

```python
class Foo:
def __init__(self, s: str):
self.x: set[str] = {s} if s else set()

print(reveal_type(Foo.x))  # mypy only
```

On Fri, Sep 24, 2021 at 7:58 AM Robert Latest via Python-list <
python-list@python.org> wrote:

> Hi all,
>
> this just caused me several hours of my life until I could whittle it down
> to
> this minimal example. Simple question: Why is the x member of object "foo"
> modified by initializing "bar"?
>
> Obviously, initializing foo with None doesn't set foo.x at all. So I guess
> x
> stays a class property, not an instance property. And instantiating bar
> just
> added an item to the class property but didn't instantiate a new set. So
> basically, neither foo nor bar ever had their "own" x, right?
>
> Oooohh, dangerous! Never use mutable types in type hint, unless it's in
> explicit dataclasses (which automatically add an appropriate __init__()?)
>
> Now I must fine-comb all my code for more of these.
>
> class Foo():
> x : set = set()
>
> def __init__(self, s):
> if s:
> self.x.add(s)
>
> foo = Foo(None)
> print(foo.x) # prints 'set()'
> bar = Foo('abc')
> print(foo.x) # prints '{'abc'}
>
> --
> https://mail.python.org/mailman/listinfo/python-list
>
-- 
https://mail.python.org/mailman/listinfo/python-list

Re: Type annotation pitfall

[Greg Ewing]

On 24/09/21 5:48 pm, Robert Latest wrote:

Never use mutable types in type hint,


No, the lesson is: Don't mutate a shared object if you don't want
the changes to be shared.

If you want each instance to have its own set object, you need to
create one for it in the __init__ method, e.g.

class Foo():
 x : set

 def __init__(self, s):
 self.x = set()
 if s:
 self.x.add(s)

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

Different "look and feel" of some built-in functions

[Steve Keller]

Why do some built-in Python functions feel so differently:

For example sum(), all(), any() expect exactly one argument which is a
sequence to operate on, i.e. a list, an iterator or a generator etc.

sum([1,2,3,4])
sum(range(1, 101))
sum(2**i for i in range(10))
all([True, False])
any(even, {1,2,3,4})

while other functions like set.union() and set.intersection() work on
a list of arguments but not on a sequence:

set.intersection({1,2,3}, {3,4,5})

but

set.union(map(...))   # does not work
set.intersection(list(...))   # does not work

and you have to use a * instead

set.union(*map(...))

etc.

Is this just for historical reason?  And wouldn't it be possible and
desirable to have more consistency?

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

Re: Flush / update GUIs in PyQt5 during debugging in PyCharm

[DFS]

On 9/24/2021 12:46 AM, Mohsen Owzar wrote:

Hi Guys
I've written a GUI using PyQt5 and in there I use StyleSheets (css) for the 
buttons and labels to change their background- and foreground-colors and their 
states as well.
Because my program doesn't function correctly, I try to debug it in my IDE 
(PyCharm).
The problem is that during debugging, when I change some attributes of a button 
or label, let say its background-color, I can not see this modification of the 
color until the whole method or function is completed.
I believe that I have seen somewhere during my searches and googling that one 
can flush or update the GUI after each step/action is done.
But until now I couldn't manage it and I don't know where I have to invoke 
flush/update command in PyCharm.
If anyone has done this before and knows about it, I would very appreciate 
seeing his solution.

Regards
Mohsen



screen:
form.repaint()

individual widgets:
form.widget.repaint()


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

Re: Type annotation pitfall

[Chris Angelico]

On Fri, Sep 24, 2021 at 11:43 PM Peter Saalbrink
 wrote:
>
> I don't think this has anything to do with typing or providing type hints.
> The type hint is the `: set` part, not the `= set()` part.
> You can declare the type without assigning to the variable.
> Indeed, as you already said, `x` is a class property here, and is shared
> amongst instances of the class.
> It might be a good idea to move the attribute assignment to the `__init__`
> method.
>
> In the following way, you can safely provide the type hint:
>
> ```python
> class Foo:
> x: set
>
> def __init__(self, s):
> self.x = set()
> if s:
> self.x.add(s)
> ```
>

To be clear, this isn't a case of "never use mutables as class
attributes"; often you *want* a single mutable object to be shared
among instances of a class (so they can all find each other, perhaps).
If you want each instance to have its own set, you construct a new set
every object initialization; if you want them to all use the same set,
you construct a single set and attach it to the class. Neither is
wrong, they just have different meanings.

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

Re: Different "look and feel" of some built-in functions

[Chris Angelico]

On Fri, Sep 24, 2021 at 11:47 PM Steve Keller  wrote:
>
> Why do some built-in Python functions feel so differently:
>
> For example sum(), all(), any() expect exactly one argument which is a
> sequence to operate on, i.e. a list, an iterator or a generator etc.
>
> sum([1,2,3,4])
> sum(range(1, 101))
> sum(2**i for i in range(10))
> all([True, False])
> any(even, {1,2,3,4})
>
> while other functions like set.union() and set.intersection() work on
> a list of arguments but not on a sequence:
>
> set.intersection({1,2,3}, {3,4,5})
>
> but
>
> set.union(map(...))   # does not work
> set.intersection(list(...))   # does not work
>
> and you have to use a * instead
>
> set.union(*map(...))
>
> etc.
>
> Is this just for historical reason?  And wouldn't it be possible and
> desirable to have more consistency?
>

The ones you're calling off the set class are actually meant to be methods.

>>> s = {1,2,3}
>>> s.intersection({3,4,5})
{3}

They expect a set, specifically, as the first argument, because
normally that one goes before the dot. If you want to call the unbound
method with two arguments, that's fine, but it's not the intended use,
so you have to basically fudge it to look like a normal method call :)
That's why it doesn't take a sequence.

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

Re: XML Considered Harmful

[Mostowski Collapse]

BTW: I think its problematic to associate Java with XML.

Michael F. Stemper schrieb am Dienstag, 21. September 2021 um 20:12:33 UTC+2:
> On the prolog thread, somebody posted a link to: 
>  

The above linke is very old, from 2004, and might apply
how Java presented itself back in those days. But since
the Jigsaw project, XML has practically left Java.

Its all not anymore part of the javax.* or java.* namespace,
Oracle got rid of XML technologies housing in these 
namespaces, and there is now the jakarta.* namespace.

Example JAXB:
Jakarta XML Binding (JAXB; formerly Java Architecture for XML Binding) 
https://de.wikipedia.org/wiki/Jakarta_XML_Binding

If I remember well, also XML never went into the Java
Language Specification, unlike the Scala programming 
language, where you can have XML literals:

XML literals in scala
https://tuttlem.github.io/2015/02/24/xml-literals-in-scala.html
 
An easy protection against tampered XML data vulnerabilities 
is DTD or some other XML schema language. It can at least catch
problems that are in the scope of the schema language.
-- 
https://mail.python.org/mailman/listinfo/python-list

Re: XML Considered Harmful

[Mostowski Collapse]

Or then use cryptographic methods to protect your XML
file when in transit. Like encryption and/or signatures.

Mostowski Collapse schrieb am Freitag, 24. September 2021 um 15:46:27 UTC+2:
> BTW: I think its problematic to associate Java with XML.
> Michael F. Stemper schrieb am Dienstag, 21. September 2021 um 20:12:33 UTC+2: 
> > On the prolog thread, somebody posted a link to: 
> > 
> The above linke is very old, from 2004, and might apply 
> how Java presented itself back in those days. But since 
> the Jigsaw project, XML has practically left Java. 
> 
> Its all not anymore part of the javax.* or java.* namespace, 
> Oracle got rid of XML technologies housing in these 
> namespaces, and there is now the jakarta.* namespace. 
> 
> Example JAXB: 
> Jakarta XML Binding (JAXB; formerly Java Architecture for XML Binding) 
> https://de.wikipedia.org/wiki/Jakarta_XML_Binding 
> 
> If I remember well, also XML never went into the Java 
> Language Specification, unlike the Scala programming 
> language, where you can have XML literals: 
> 
> XML literals in scala 
> https://tuttlem.github.io/2015/02/24/xml-literals-in-scala.html 
> 
> An easy protection against tampered XML data vulnerabilities 
> is DTD or some other XML schema language. It can at least catch 
> problems that are in the scope of the schema language.
-- 
https://mail.python.org/mailman/listinfo/python-list

Re: Different "look and feel" of some built-in functions

[Dieter Maurer]

Steve Keller wrote at 2021-9-24 11:48 +0200:
>Why do some built-in Python functions feel so differently:

Because the typical use cases are different

>For example sum(), all(), any() expect exactly one argument which is a
>sequence to operate on, i.e. a list, an iterator or a generator etc.
>
>sum([1,2,3,4])
>sum(range(1, 101))
>sum(2**i for i in range(10))
>all([True, False])
>any(even, {1,2,3,4})

You use those functions typically on a large number
of operands, typically already collected together via some form
of iterator.
If you want to compute the sum of a few operands, you
would usually not use `sum` but `o1 + o2 + ...`.

>while other functions like set.union() and set.intersection() work on
>a list of arguments but not on a sequence:
>
>set.intersection({1,2,3}, {3,4,5})

Those operations are typically applied to a small number
of operands. You would need to build an iterator in that
case should the functions only accept iterators.



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

Re: Different "look and feel" of some built-in functions

[Dieter Maurer]

Stefan Ram wrote at 2021-9-24 14:53 GMT:
>Steve Keller  writes:
>>Why do some built-in Python functions feel so differently:
>
>|>>> s = set()
>|>>> s.add( 1 )
>|>>>
>
>
>|>>> l = []
>|>>> l.add( 1 )
>
>|
>|Traceback (most recent call last):
>|  File "", line 1, in 
>|AttributeError: 'list' object has no attribute 'add'
>|
>|>>> l.append( 1 )

A list is ordered. Therefore, it is important where
in this order an element is added. Thus, for a list,
`append` is a better name than `add` -- because it already
tells us in the name where it adds the new element.

A set is unordered. Therefore, the name `append` does not make sense
for a set.



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

Re: Different "look and feel" of some built-in functions

[Chris Angelico]

On Sat, Sep 25, 2021 at 3:42 AM Stefan Ram  wrote:
>
> "Dieter Maurer"  writes:
> >A list is ordered. Therefore, it is important where
> >in this order an element is added. Thus, for a list,
> >`append` is a better name than `add` -- because it already
> >tells us in the name where it adds the new element.
>
>   In a collection of texts, which is not large but mixed from
>   many different fields and genres, I find (using a Python
>   script, of course) eight hits for "added to the list" :
>
> |s and rock n roll can be added to the list. As - Taylor, 2012
> | of opinion was probably added to the list tow - from a dictionary
> |gg and his wife might be added to the list of  - Sir Walter Scott
> |ships when your name was added to the list. In - Percy Bysshe Shelley
> |em that wealth should be added to the list. No - Henry
> |n was discovered and was added to the list of  - from a dictionary
> |nd said his name must be added to the list, or - Mark Twain
>
>   . There was no hit for "appended to the list".
>
>   When one says "add something to a list", it is usually understood
>   that one adds it at the /end/. In the case of traditional written
>   lists it is not possible in any other way.
>

When I add something to the shopping list, it is not added to the end.
It is added anywhere that there is room. If you care about the
sequence, you would say "add to the end". Or, using the more technical
and briefer word, "append". Most of the lists you're seeing there are
not being added to the end of; for instance, I would guess that quite
a few of them are inherently sorted lists, so you would be adding a
person's name in affabeck lauder, or adding something to a particular
ranked position, or whatever else. This is not the same thing.

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

Re: XML Considered Harmful

[Peter J. Holzer]

On 2021-09-21 19:46:19 -0700, Dan Stromberg wrote:
> On Tue, Sep 21, 2021 at 7:26 PM Michael F. Stemper <
> michael.stem...@gmail.com> wrote:
> > If XML is not the way to package data, what is the recommended
> > approach?
> >
> 
> I prefer both JSON and YAML over XML.
> 
> XML has both elements and tags, but it didn't really need both.

I think you meant "both elements and attributes". Tags are how you
denote elements, so they naturally go together.

I agree that for representing data (especially object-oriented data) the
distiction between (sub-)elements and attributes seems moot (should
represent that field as an attribute or a field?), but don't forget that
XML was intended to replace SGML, and that SGML was intended to mark up
text, not represent any data.

Would you really want to write

Mr. Smiths point was corroborated by
Ms. Jones point that bla, bla, which
seemed more plausibe than Mr. Willam
claim that blub, blub.

as

Mr. Smiths point was corroborated by
Ms. Jones point that bla, bla, which
seemed more plausibe than Mr. Willam
claim that blub, blub.

or

Mr. Smith<(defendant>s point was
corroborated by Ms. Jones point that bla,
bla, which seemed more plausibe than Mr. 
Willam claim that blub,
blub.

?

I probably chose an example (no doubt influenced by the fact that SGML
was originally invented to digitize court decisions) which is too simple
(in HTML I often see many attributes on a single element, even with
CSS), but even here you can see that attributes add clarity.

hp

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


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

Re: XML Considered Harmful

[Peter J. Holzer]

On 2021-09-23 06:53:10 -0600, Mats Wichmann wrote:
> The problem with csv is that a substantial chunk of the world seems to
> live inside Excel,

This is made sp much worse by Excel being exceptionally bad at reading
CSV.

Several hundred genes were recently renamed because Excel was unable to
read their names as simply strings and insisted on interpreting them as
something else (e.g. dates).

hp

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


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

Re: XML Considered Harmful

[Peter J. Holzer]

On 2021-09-21 13:12:10 -0500, Michael F. Stemper wrote:
> I read this page right when I was about to write an XML parser
> to get data into the code for a research project I'm working on.
> It seems to me that XML is the right approach for this sort of
> thing, especially since the data is hierarchical in nature.
> 
> Does the advice on that page mean that I should find some other
> way to get data into my programs, or does it refer to some kind
> of misuse/abuse of XML for something that it wasn't designed
> for?
> 
> If XML is not the way to package data, what is the recommended
> approach?

There are a gazillion formats and depending on your needs one of them
might be perfect. Or you may have to define you own bespoke format (I
mean, nobody (except Matt Parker) tries to represent images or videos as
CSVs: There's PNG and JPEG and WEBP and H.264 and AV1 and whatever for
that).

Of the three formats discussed here my take is:

CSV: Good for tabular data of a single data type (strings). As soon as
there's a second data type (numbers, dates, ...) you leave standard
territory and are into "private agreements".

JSON: Has a few primitive data types (bool, number, string) and a two
compound types (list, dict(string -> any)). Still missing many
frequently used data types (e.g. dates) and has no standard way to
denote composite types. But its simple and if it's sufficient for your
needs, use it.

XML: Originally invented for text markup, and that shows. Can represent
different types (via tags), can define those types (via DTD and/or
schemas), can identify schemas in a globally-unique way and you can mix
them all in a single document (and there are tools available to validate
your files). But those features make it very complex (you almost
certainly don't want to write your own parser) and you really have to
understand the data model (especiall namespaces) to use it.


You can of course represent any data in any format if you jump through
enough hoops, but the real question is "does the data I have fit
naturally within the data model of the format I'm trying to use". If it
doesn't, look for something else. For me, CSV, JSON and XML form a
hierarchy where each can naturally represent all the data of its
predecessors, but not vice versa.

hp

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


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

Re: Different "look and feel" of some built-in functions

[Steve Keller]

"Dieter Maurer"  writes:

> Steve Keller wrote at 2021-9-24 11:48 +0200:
> >Why do some built-in Python functions feel so differently:
> 
> Because the typical use cases are different
> 
> [...]
> 
> >while other functions like set.union() and set.intersection() work on
> >a list of arguments but not on a sequence:
> >
> >set.intersection({1,2,3}, {3,4,5})
> 
> Those operations are typically applied to a small number
> of operands. You would need to build an iterator in that
> case should the functions only accept iterators.

In my experience I need intersection and union on a list of sets, set
of sets or a map() returning sets much more often.  E.g. in some
mathematical problems, and in automaton theory (IIRC, computing of LR
or LALR sets, converting NFA to DFA, minimizing DFA), many graph
algorithms traversing the nodes (shortest path, ...), and so on).

Intersection and union of two sets is actually often seen in naïve
programming in loops like

for t in (some_sequence):
s.union(t)

where set.union(*(some_sequence)) would be much more elegant.

BTW, I like how the min() and max() functions allow both ways of being
called.

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

Re: XML Considered Harmful

[dn via Python-list]

On 25/09/2021 06.59, Peter J. Holzer wrote:
> There are a gazillion formats and depending on your needs one of them
> might be perfect. Or you may have to define you own bespoke format (I
> mean, nobody (except Matt Parker) tries to represent images or videos as
> CSVs: There's PNG and JPEG and WEBP and H.264 and AV1 and whatever for
> that).
> 
> Of the three formats discussed here my take is:
> 
> CSV: Good for tabular data of a single data type (strings). As soon as
> there's a second data type (numbers, dates, ...) you leave standard
> territory and are into "private agreements".
> 
> JSON: Has a few primitive data types (bool, number, string) and a two
> compound types (list, dict(string -> any)). Still missing many
> frequently used data types (e.g. dates) and has no standard way to
> denote composite types. But its simple and if it's sufficient for your
> needs, use it.
> 
> XML: Originally invented for text markup, and that shows. Can represent
> different types (via tags), can define those types (via DTD and/or
> schemas), can identify schemas in a globally-unique way and you can mix
> them all in a single document (and there are tools available to validate
> your files). But those features make it very complex (you almost
> certainly don't want to write your own parser) and you really have to
> understand the data model (especiall namespaces) to use it.

and YAML?
-- 
Regards,
=dn
-- 
https://mail.python.org/mailman/listinfo/python-list

Re: XML Considered Harmful

[Chris Angelico]

On Sat, Sep 25, 2021 at 8:53 AM dn via Python-list
 wrote:
>
> On 25/09/2021 06.59, Peter J. Holzer wrote:
> > There are a gazillion formats and depending on your needs one of them
> > might be perfect. Or you may have to define you own bespoke format (I
> > mean, nobody (except Matt Parker) tries to represent images or videos as
> > CSVs: There's PNG and JPEG and WEBP and H.264 and AV1 and whatever for
> > that).
> >
> > Of the three formats discussed here my take is:
> >
> > CSV: Good for tabular data of a single data type (strings). As soon as
> > there's a second data type (numbers, dates, ...) you leave standard
> > territory and are into "private agreements".
> >
> > JSON: Has a few primitive data types (bool, number, string) and a two
> > compound types (list, dict(string -> any)). Still missing many
> > frequently used data types (e.g. dates) and has no standard way to
> > denote composite types. But its simple and if it's sufficient for your
> > needs, use it.
> >
> > XML: Originally invented for text markup, and that shows. Can represent
> > different types (via tags), can define those types (via DTD and/or
> > schemas), can identify schemas in a globally-unique way and you can mix
> > them all in a single document (and there are tools available to validate
> > your files). But those features make it very complex (you almost
> > certainly don't want to write your own parser) and you really have to
> > understand the data model (especiall namespaces) to use it.
>
> and YAML?

Invented because there weren't enough markup languages, so we needed another?

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

Re: XML Considered Harmful

[David L Neil via Python-list]

On 25/09/2021 11.00, Chris Angelico wrote:

> Invented because there weren't enough markup languages, so we needed another?

Anything You Can Do I Can Do Better
https://www.youtube.com/watch?v=_UB1YAsPD6U

-- 
Regards =dn
-- 
https://mail.python.org/mailman/listinfo/python-list

Re: Different "look and feel" of some built-in functions

[Greg Ewing]

On 25/09/21 10:15 am, Steve Keller wrote:

BTW, I like how the min() and max() functions allow both ways of being
called.


That wouldn't work for set.union and set.intersection, because as
was pointed out, they're actually methods, so set.union(some_seq)
is a type error:

>>> a = {1, 2}
>>> b = {3, 4}
>>> set.union([a, b])
Traceback (most recent call last):
  File "", line 1, in 
TypeError: descriptor 'union' for 'set' objects doesn't apply to a 
'list' object


I suppose they could be fiddled somehow to make it possible, but
that would be turning them into special cases that break the rules.
It would be better to provide separate functions, as was done with
sum().

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

Re: XML Considered Harmful

[Jon Ribbens via Python-list]

On 2021-09-24, Chris Angelico  wrote:
> On Sat, Sep 25, 2021 at 8:53 AM dn via Python-list
> wrote:
>> On 25/09/2021 06.59, Peter J. Holzer wrote:
>> > CSV: Good for tabular data of a single data type (strings). As soon as
>> > there's a second data type (numbers, dates, ...) you leave standard
>> > territory and are into "private agreements".

CSV is not good for strings, as there is no one specification of how to
encode things like newlines and commas within the strings, so you may
find that your CSV data transfer fails or even silently corrupts data.

>> > JSON: Has a few primitive data types (bool, number, string) and a two
>> > compound types (list, dict(string -> any)). Still missing many
>> > frequently used data types (e.g. dates) and has no standard way to
>> > denote composite types. But its simple and if it's sufficient for your
>> > needs, use it.

JSON Schema provides a way to denote composite types.

>> > XML: Originally invented for text markup, and that shows. Can represent
>> > different types (via tags), can define those types (via DTD and/or
>> > schemas), can identify schemas in a globally-unique way and you can mix
>> > them all in a single document (and there are tools available to validate
>> > your files). But those features make it very complex (you almost
>> > certainly don't want to write your own parser) and you really have to
>> > understand the data model (especiall namespaces) to use it.
>>
>> and YAML?
>
> Invented because there weren't enough markup languages, so we needed
> another?

Invented as a drunken bet that got out of hand, and used by people who
don't realise this.
-- 
https://mail.python.org/mailman/listinfo/python-list

Re: Different "look and feel" of some built-in functions

[Oscar Benjamin]

On Sat, 25 Sept 2021 at 00:37, Greg Ewing 
wrote:

> On 25/09/21 10:15 am, Steve Keller wrote:
> > BTW, I like how the min() and max() functions allow both ways of being
> > called.
>
> That wouldn't work for set.union and set.intersection, because as
> was pointed out, they're actually methods, so set.union(some_seq)
> is a type error:
>
>  >>> a = {1, 2}
>  >>> b = {3, 4}
>  >>> set.union([a, b])
> Traceback (most recent call last):
>File "", line 1, in 
> TypeError: descriptor 'union' for 'set' objects doesn't apply to a
> 'list' object
>
> I suppose they could be fiddled somehow to make it possible, but
> that would be turning them into special cases that break the rules.
> It would be better to provide separate functions, as was done with
> sum().
>

A separate union function would be good. Even in a situation where all
inputs are assured to be sets the set.union method fails the base case:

>>> sets = []
>>> set.union(*sets)
Traceback (most recent call last):
  File "", line 1, in 
TypeError: descriptor 'union' of 'set' object needs an argument

In the case of intersection perhaps the base case should be undefined.

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

Re: Different "look and feel" of some built-in functions

[Chris Angelico]

On Sat, Sep 25, 2021 at 10:56 AM Oscar Benjamin
 wrote:
>
> On Sat, 25 Sept 2021 at 00:37, Greg Ewing 
> wrote:
>
> > On 25/09/21 10:15 am, Steve Keller wrote:
> > > BTW, I like how the min() and max() functions allow both ways of being
> > > called.
> >
> > That wouldn't work for set.union and set.intersection, because as
> > was pointed out, they're actually methods, so set.union(some_seq)
> > is a type error:
> >
> >  >>> a = {1, 2}
> >  >>> b = {3, 4}
> >  >>> set.union([a, b])
> > Traceback (most recent call last):
> >File "", line 1, in 
> > TypeError: descriptor 'union' for 'set' objects doesn't apply to a
> > 'list' object
> >
> > I suppose they could be fiddled somehow to make it possible, but
> > that would be turning them into special cases that break the rules.
> > It would be better to provide separate functions, as was done with
> > sum().
> >
>
> A separate union function would be good. Even in a situation where all
> inputs are assured to be sets the set.union method fails the base case:
>
> >>> sets = []
> >>> set.union(*sets)
> Traceback (most recent call last):
>   File "", line 1, in 
> TypeError: descriptor 'union' of 'set' object needs an argument
>
> In the case of intersection perhaps the base case should be undefined.
>

Rather than calling the unbound method, why not just call it on an
empty set? That defines your base case as well.

set().union(*sets)

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

Re: Different "look and feel" of some built-in functions

[Oscar Benjamin]

On Sat, 25 Sept 2021 at 02:01, Chris Angelico  wrote:

> On Sat, Sep 25, 2021 at 10:56 AM Oscar Benjamin
>  wrote:
> >
> > On Sat, 25 Sept 2021 at 00:37, Greg Ewing 
> > wrote:
> > > I suppose they could be fiddled somehow to make it possible, but
> > > that would be turning them into special cases that break the rules.
> > > It would be better to provide separate functions, as was done with
> > > sum().
> > >
> >
> > A separate union function would be good. Even in a situation where all
> > inputs are assured to be sets the set.union method fails the base case:
> >
> > >>> sets = []
> > >>> set.union(*sets)
> > Traceback (most recent call last):
> >   File "", line 1, in 
> > TypeError: descriptor 'union' of 'set' object needs an argument
> >
> > In the case of intersection perhaps the base case should be undefined.
> >
>
> Rather than calling the unbound method, why not just call it on an
> empty set? That defines your base case as well.
>
> set().union(*sets)
>

That is indeed what I do but it seems unnatural compared to simply
union(*sets). It shouldn't be necessary to create a redundant empty set
just to compute the union of some other sets. If there was a union function
then I don't think I would ever use the union method.


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

Re: Different "look and feel" of some built-in functions

[Chris Angelico]

On Sat, Sep 25, 2021 at 11:11 AM Oscar Benjamin
 wrote:
>
> On Sat, 25 Sept 2021 at 02:01, Chris Angelico  wrote:
>>
>> On Sat, Sep 25, 2021 at 10:56 AM Oscar Benjamin
>>  wrote:
>> >
>> > On Sat, 25 Sept 2021 at 00:37, Greg Ewing 
>> > wrote:
>> > > I suppose they could be fiddled somehow to make it possible, but
>> > > that would be turning them into special cases that break the rules.
>> > > It would be better to provide separate functions, as was done with
>> > > sum().
>> > >
>> >
>> > A separate union function would be good. Even in a situation where all
>> > inputs are assured to be sets the set.union method fails the base case:
>> >
>> > >>> sets = []
>> > >>> set.union(*sets)
>> > Traceback (most recent call last):
>> >   File "", line 1, in 
>> > TypeError: descriptor 'union' of 'set' object needs an argument
>> >
>> > In the case of intersection perhaps the base case should be undefined.
>> >
>>
>> Rather than calling the unbound method, why not just call it on an
>> empty set? That defines your base case as well.
>>
>> set().union(*sets)
>
>
> That is indeed what I do but it seems unnatural compared to simply 
> union(*sets). It shouldn't be necessary to create a redundant empty set just 
> to compute the union of some other sets. If there was a union function then I 
> don't think I would ever use the union method.
>

Maybe, but if you start with a set, then you define the base case, and
it also is quite happy to take non-set arguments:

>>> set().union([1,2,3], map(int, "234"), {3:"three",4:"four",5:"five"})
{1, 2, 3, 4, 5}

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

Re: XML Considered Harmful

[Greg Ewing]

On 25/09/21 6:29 am, Peter J. Holzer wrote:

don't forget that
XML was intended to replace SGML, and that SGML was intended to mark up
text, not represent any data.


And for me this is the number one reason why XML is the wrong
tool for almost everything it's used for nowadays.

It's bizarre. It's as though there were a large community of
professional builders who insisted on using hammers to drive
scews, and extolled the advantages of doing so.

--
Greg

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

Re: XML Considered Harmful

[Greg Ewing]

On 25/09/21 6:34 am, Peter J. Holzer wrote:

Several hundred genes were recently renamed because Excel was unable to
read their names as simply strings and insisted on interpreting them as
something else (e.g. dates).


Another fun one I've come across is interpreting phone numbers
as floating point and writing them out again with exponents...

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

Re: XML Considered Harmful

[Greg Ewing]

On 25/09/21 10:51 am, dn wrote:

XML: Originally invented for text markup, and that shows. Can represent
different types (via tags), can define those types (via DTD and/or
schemas), can identify schemas in a globally-unique way and you can mix
them all in a single document (and there are tools available to validate
your files). But those features make it very complex


And for all that complexity, it still doesn't map very well
onto the kinds of data structures used inside programs (lists,
structs, etc.), so you end up having to build those structures
on top of it, and everyone does that in a different way.

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

Re: XML Considered Harmful

[Greg Ewing]

On 25/09/21 11:00 am, Chris Angelico wrote:

On Sat, Sep 25, 2021 at 8:53 AM dn via Python-list
 wrote:


and YAML?


Invented because there weren't enough markup languages, so we needed another?


There were *too many* markup languages, so we invented another!

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